Uptime monitoring

Why it matters

Software can look healthy on a developer's laptop and still fail for customers in another region. Uptime monitoring watches the service the way a user would: from outside the private network, on a recurring schedule.

When a check fails, the goal is not noise. The goal is a verified signal that something important stopped working, so the team can investigate while the blast radius is still small.

How it works

A monitor stores a target such as https://api.example.com/health, a schedule, and success rules. At each interval the checker sends a request, records timing and status, and compares the result to those rules.

Success rules often include HTTP status ranges, maximum response time, required keywords, or JSON fields. A single failure may trigger retries or confirmation from another region before an incident opens.

History accumulates as a timeline of successes and failures. That history powers uptime calculations, incident evidence, and public status pages when you choose to share them.

Practical example

A SaaS team monitors https://api.example.com/health every minute. The assertion requires status 200 and a JSON field status equal to ok. When the endpoint returns 503 twice and a second region confirms the failure, incident verification begins and the on-call channel receives an alert.

Common misconception

One failed check means the site is down

A single failed check can be a brief network blip, a cold start, or a regional path problem. Serious monitoring confirms failures before treating them as outages, which reduces false positives without hiding real downtime.

Commonly confused with

Uptime monitoring versus observability

Uptime monitoring answers whether the service is reachable and meeting external expectations. Observability usually means deep internal telemetry such as logs, metrics, and traces. Both matter. They solve different jobs.

How Fajita handles this

Fajita can check websites and APIs on a recurring schedule, evaluate status-code, response-time, keyword, and JSON-path assertions, then begin incident verification when a scheduled check fails.

You can create your first monitor and test it before monitoring begins.

Operational checklist

• Pick the URL or endpoint customers depend on.
• Set an interval that matches how quickly you need to know.
• Define assertions that match real success, not only HTTP 200.
• Confirm failures before paging people when false positives are costly.
• Connect an alert channel before you need it in an emergency.