External checks, incidents, and notifications.
Uptime monitors check an HTTP service from outside its server. They complement agent metrics by measuring whether a user can reach the application and receive an acceptable response.
Choose a URL, HTTP method, exact expected status code, interval, timeout, and the number of confirmations required before a failure becomes downtime. Optional checks can match response text and response headers, send request headers or a body, and monitor the certificate for an HTTPS URL.
GET https://example.com/health
Accept: application/jsonAn endpoint should return a non-success response when the application cannot safely serve traffic. Avoid embedding secrets in the URL.
ServerChirp opens an incident after the configured number of consecutive confirmed failures and resolves it when the check recovers. Incident history keeps the start time, resolution time, and recorded cause; individual check events retain response status, latency, or error details.
A single failed request does not always mean an outage. Choose confirmation settings that match the service's traffic and tolerance for brief network failures.
Monitor history shows response time and uptime over the selected period. Compare latency changes with deployments, server metrics, database pressure, and traffic before attributing the cause.
Route incident transitions through the team's notification channels. Alert the people who can act and avoid sending the same event through multiple overlapping channels unless escalation requires it.
For planned work, communicate through a status page before making a disruptive change. Do not disable the monitor simply to keep the chart green; a recorded maintenance interruption is more useful than missing history.