Your app defines healthy. We hold it to that.
Expose a health route that returns ok, degraded, or down. UptimeStatus calls it on a schedule, keeps the history, and owns the alerting.
A contract small enough to write before lunch.
A 200 from your homepage proves the web server is up. It says nothing about the database, the queue, or the third-party API your checkout depends on. Only your application can see those, and it already knows when they are wrong.
So put that knowledge in a route. Return a status of ok, degraded, or down, and optionally a map of named booleans for the details. UptimeStatus polls it, records what it said, and reacts.
# GET https://api.yourcompany.com/health { "status": "degraded", "checks": { "database": true, "redis": true, "queue_backlog": false } }
Checked from outside, where your app cannot vouch for itself.
A health route inside a monolith that is down cannot tell anyone it is down. The polling, the history, and the alerting have to live somewhere else.
UptimeStatus calls your route on the schedule you choose, stores every verdict with its sub-checks and response time, and turns the transition to down into an incident on your channels. Degraded states stay visible without waking anyone up.
What health checks include.
- Three states, not two your route returns ok, degraded, or down. Degraded is visible in the dashboard and history without paging anyone.
- Named sub-checks an optional checks map of booleans (database, redis, queue depth, disk space) is stored with every result for diagnosis.
- Point it at any path the monitor calls its URL by default, or set a path like /health in the monitor config to hit a dedicated route.
- Strict by default a non-2xx response, a timeout past 15 seconds, or a body with no status field all count as down.
- Automatic incidents the transition to down opens a timeline incident with the reported cause and notifies your channels.
- Latency on every call response time is recorded with each result, so a health route that is getting slower shows up in the history.
Any framework. It is just a JSON route.
Rails, Laravel, Express, Django, Stacks, a Go binary: if it can return a small JSON object, it can report health. There is no SDK to adopt and no format to migrate to later, and the same route works unchanged if you ever move monitoring tools.
Health checks, answered.
What does my endpoint need to return?
JSON with a status field set to ok, degraded, or down, plus an optional checks object mapping names to booleans. Only the status field drives the monitor state; the checks map is stored with the result so you can see which dependency went red.
How is this different from uptime monitoring?
An uptime check asks whether the endpoint responds. A health check asks the application itself. Your app can see things a probe cannot: the database connection pool, the queue backlog, a downstream API. The health route reports that verdict and we treat it as the source of truth.
What does degraded actually do?
The monitor shows degraded and the result is recorded in the history, but no incident opens and nobody gets paged. Incidents are reserved for the transition to down. Degraded is for the "working, but worth a look" middle ground.
What if the endpoint returns HTML or times out?
Both count as down. A response with no parseable status field is a failure, and the check gives up after 15 seconds. A health route that cannot answer a simple GET quickly is itself a finding.
How often is the route called?
As often as every 30 seconds on Pro and every 5 minutes on Free. Self-hosted installs set their own schedule. Keep the route cheap and side-effect free, since it will be called a lot.
Should the health route be public?
The checker sends a plain GET, so the route needs to be reachable without credentials. Return only status and booleans, never internals like hostnames or versions, and use an unguessable path if you want it out of casual reach.
Pairs well with.
Uptime monitoring
Outside-in checks from six regions for the plain "does it respond" question, as often as every 30 seconds.
Learn moreCron monitoring
For work with no URL to call: your scheduled jobs ping us, and silence past the grace period is the alert.
Learn moreIncident management
Every failure becomes a timeline incident with a cause, updates, and a resolution, not a line in a log.
Learn moreStart monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.