Sign in

Uptime and status pages

Know when it stops answering, and tell your customers.

Unhandled checks your endpoints every minute from outside your infrastructure. An outage opens only after several failed checks in a row that most regions agree on, and your team can pick it up on the monitor page. The same monitors build a public status page, where you post incidents and maintenance for the people who subscribed.

Sign inRead the docs
Four check types
HTTP, TCP, DNS and heartbeat
Confirmed outages
Most regions have to agree it is down
Health mode
Reads AdonisJS health check reports
Status pages
Incidents, maintenance and subscribers
#monitors

Every endpoint, checked every minute

Add an HTTP, TCP, DNS or heartbeat monitor to any environment of a project. The Uptime page lists each one with 90 days of availability, its uptime, when it was last checked and how fast it answered.

  • Connection resets, timeouts and 502, 503 and 504 responses are retried before a check counts as failed
  • An outage opens after 3 failed checks in a row and resolves after 2 passing ones, or the counts you set
  • Targets on private or reserved addresses are refused when you save and again at check time
#checks

Read the response your users got

A failed check keeps its status code, its response headers and the first 16,384 characters of the body. Latest checks opens on the failures and state changes in the range, so the 503 that started an outage is one click away.

  • A test check before you save shows DNS, connect, TLS and first byte times, and a curl, nc or dig command to rerun it
  • A slow check, or a certificate that expires within 14 days, counts as a warning
  • Anyone on the project can acknowledge, assign and comment on the latest outage
#health-mode

Health reports, not just status codes

Turn on health mode and Unhandled parses the JSON your health route returns instead of trusting the status code alone. The format matches the AdonisJS health check report, so an AdonisJS app works without changes.

  • isHealthy set to false fails the check, whatever the status code
  • An entry with the status warning or error passes as a warning
  • The monitor page shows every entry of the latest report for each period
GET /health
{
  "isHealthy": true,
  "checks": [
    { "name": "database", "status": "ok" },
    { "name": "payments-api", "status": "warning" }
  ]
}
#status-page

A status page built from your monitors

Each environment can publish one status page at /status/<slug>. Every monitor you show on it becomes a resource with its status, 90 daily bars and its uptime over those 90 days.

  • Degraded Performance, Partial Outage and Major Outage come from the checks, so nobody has to edit the page
  • RSS and Atom feeds carry every incident and maintenance window
  • When the app is down, a copy saved at least once a minute is served instead
#incidents

You decide what customers read

Outages never post incidents by themselves. Report one from the Incidents tab with a severity and the affected resources, then post updates as it moves from Investigating to Resolved.

  • Keep an incident private while you look into it, and make it public later
  • Schedule maintenance ahead, and checks inside the window do not count against uptime
  • Each update can email the subscribers who follow the affected resources
#subscribers

Subscribers follow the parts they use

Visitors subscribe by email to every component or only the ones they pick. Each address confirms through a link valid for 7 days before it gets anything, and every update email has an unsubscribe link.

  • A live preview shows the page in light and dark themes, at desktop and phone sizes
  • Choose which monitors appear on the page, in the order of the Monitoring tab
  • Admins see who subscribed, to what, and whether they confirmed

Works with

Where your team hears about it

#faq

Questions

In the docs

How it works, in detail

Every feature

Try it on your own stack.

Every feature is on every plan, priced by the telemetry you send.

Sign inRead the docs