Fajita watches four kinds of things and tells your team when one of them stops behaving. It checks on a schedule, confirms a real failure before it wakes anyone, and gives you a public place to communicate what is happening.
The four monitor types
| Type | Watches | Opens an incident when |
|---|---|---|
| Website | An HTTP or HTTPS URL | Requests fail or an assertion fails |
| API | A JSON or HTTP endpoint with headers and a body | Status, response time, or a JSON assertion fails |
| SSL certificate | A certificate's validity and expiry | The certificate is invalid, mismatched, or near expiry |
| Heartbeat | A scheduled job that checks in | The expected check-in does not arrive in time |
How a check becomes an incident
A single failed request does not open an incident. Fajita retries first, then runs verification across consecutive checks. Only a confirmed failure opens an incident, which keeps alerts trustworthy.
A scheduled check runs. On failure, Fajita retries the request. If the retry still fails, verification counts consecutive failing checks against the monitor's threshold. Once the threshold is met, an incident opens and alerts route to your channels. When checks pass again, recovery confirmation runs before the incident resolves.
What you can build in your first session
- One monitor for a real URL, tested before you save it
- An alert channel (email, Slack, Discord, or a signed webhook)
- A routing rule that decides which alerts reach which channel
- A public status page with one component mapped to your monitor
Start with Create your first monitor.