Fajita monitors your websites, APIs, certificates, and cron jobs. When something starts cooking, your team hears about it before your customers do.
1 of 8: All quiet. Four services checked on schedule. Steady rhythm, controlled warmth.
The product
Every monitor shows its status, response time, certificate health, and history in one place. This is the interface Fajita is building, with demonstration data.
No dashboards to assemble. No query language. A monitor is a URL, a schedule, and the people to tell.
The problem
Outages happen. Finding out through a support ticket is optional.
Coverage
Pick a monitor type to see what a check actually looks like.
GET https://mesa-labs.dev→ 200 OK · 212 msassert status == 200 ✓ response < 1000 ms ✓next check on schedule
Availability, status codes, and response time for every page that matters. A real request, not a ping.
Verification
Fajita will not panic after one failed request, and it will not wake you up for a hiccup.
Status pages
Publish clear incident updates, scheduled maintenance, uptime history, and recovery notices from a status page that looks like it belongs to your company.
Try the five states every status page has to be good at.
Focus
Fajita is not an observability suite, on purpose. Add the services that matter, choose where alerts go, and publish a status page. Small teams get the protection they need without turning uptime into another full-time job.
How it works
Nine steps from first monitor to uptime history, including the part where it breaks. No account, nothing leaves the page.
Pick a service. In the product this is a URL and a name; here, three ready-made examples.
Pricing
Starter, Pro, and Business. Clear monitor limits. Monthly or annual. No usage traps.
For one product and the person who answers for it.
10monitors
$9 / month
For growing products that need more monitors and faster checks.
50monitors
$19 / month
For teams and agencies watching many products at once.
Unlimitedmonitors
$39 / month
Security
A monitoring tool holds a map of what matters to you. Fajita is built to hold it carefully.
Questions
Websites, API endpoints, SSL certificates, and cron jobs or background work via heartbeat URLs. Each monitor is a real request from the outside, the same direction your customers arrive from.
A failed check triggers verification, not an alarm. Fajita re-checks before alerting anyone, so one dropped packet never pages the team. You hear about confirmed problems only.
No agent, no SDK. Website, API, and SSL checks work from the outside with zero changes. Cron monitoring needs one line: a request to a private heartbeat URL at the end of your job.
Yes. Add request headers, including authorization tokens. Credentials are encrypted at rest and never displayed back in full.
Yes. Verified incidents route to email, Slack, Discord, and webhooks, and one clear recovery message follows when the service is healthy again.
Yes. Every account can publish a status page with components, incident timelines, scheduled maintenance, subscriber updates, and uptime history. Custom domains are supported.
Fajita verifies the failure, opens an incident, alerts your configured channels, and updates your status page. When checks pass again, the incident resolves and a recovery notice goes out.
No, and on purpose. Fajita does not collect logs, traces, or infrastructure metrics. It answers one question extremely well: is your software up, and who knows about it when it is not. If you need full observability, run it alongside Fajita.
Yes. Monitoring history and account data can be exported. Your uptime record is yours.
Now. Create an account, add a monitor, and connect an alert channel. Pricing is published on the pricing page before anyone is asked to pay.