Website uptime monitoring

How uptime monitoring works

Uptime monitoring sends HTTP or HTTPS requests to your endpoints on a fixed schedule and validates the response. The check succeeds when the server returns one of your expected status codes within the response time limit. It fails — and triggers an alert — when the server is unreachable, returns an unexpected status code, or the response body does not contain a required keyword.

Configure each monitor with the precision your endpoint requires. Choose the HTTP method (GET, POST, HEAD), the full URL path including query parameters, a list of expected status codes (200, 201, 301, 401 — whatever is correct for that endpoint), and an optional keyword match in the response body. A health check returning {"status":"ok"} is verifiable at the application layer, not just at the load balancer. This catches the case where the web server responds 200 but the application behind it is broken.

Check intervals: how fast you detect an outage

Check intervals range from 1 minute (paid plans) to 60 minutes (free tier). For public-facing services, a 1-to-5-minute interval limits the detection lag to under 5 minutes from first failure to alert. For internal services where failures are less frequent but more impactful, 1-minute checks catch regressions immediately after a deployment. Paid plans support 1-minute intervals across all monitors; the free tier runs at a slower cadence suited to low-risk environments.

Status-transition alerting, without alert fatigue

Alerts fire on status transitions, not on every failed check. When a monitor transitions from up to down, one alert fires. When it recovers, a recovery notification follows. This keeps notification volume low and ensures every real outage generates exactly one page — avoiding the alert fatigue that causes on-call engineers to start ignoring their monitoring system. You can pause a monitor during planned maintenance to suppress alerts without deleting the configuration.

Alert channels: email, Slack, signed webhooks, SMS

Alert channels match your team's workflow. Email is the default. A dedicated Slack channel routes downtime alerts to the infrastructure team without noise in general channels. Webhooks (HMAC-signed for security) integrate with PagerDuty, Opsgenie, or any custom receiver — the payload includes the monitor name, URL, status code received, latency, and timestamp, giving your incident management system everything it needs to create and route an incident ticket automatically. SMS is available on paid plans for highest-urgency scenarios.

Check history, uptime % and SLA reporting

Every check is stored with a timestamp, response time, status code, and error detail. The history view in the dashboard shows a full timeline for each monitor, an uptime percentage calculated over the last N checks, and per-check latency. This data is useful for post-mortems ('when exactly did the service go down?'), for SLA reporting, and for identifying degradation trends before they become outages.

Uptime monitoring + SSL certificate monitoring together

Pair uptime monitoring with SSL certificate monitoring on the same domains. An expired SSL certificate causes a TLS handshake failure — the uptime monitor fires 'down' with no HTTP response. But you could have known 30 days earlier, when the SSL monitor first crossed its expiry threshold. Having both monitors on a domain means you get pre-failure SSL warnings and real-time uptime detection together — eliminating the two most common causes of unplanned downtime.

The free tier includes 10 uptime monitors and 10 SSL certificate monitors. The Starter plan at $15/mo scales to 25 of each, with 1-minute check intervals, webhooks, and REST API access. Uptime monitors integrate with the same alert channel configuration as SSL monitors — configure email, Slack, and webhooks once, apply them across your whole fleet.