How it works
An uptime monitor sends requests to your service at regular intervals from one or more locations. Each check verifies that:- The service responds — the connection doesn’t time out or refuse
- The response is correct — status codes, headers, or body content match expectations
- The response is fast enough — latency stays within acceptable thresholds
Types of uptime checks
| Check type | What it tests | Example |
|---|---|---|
| HTTP/HTTPS | Web endpoint availability and response | GET /health returns 200 |
| TCP | Port connectivity | Database on port 5432 is accepting connections |
| DNS | Domain resolution | api.example.com resolves to the correct IP |
| ICMP (ping) | Network reachability | Server at 10.0.1.5 responds to ping |
| Heartbeat | Service self-reporting | Cron job pings a URL on each successful run |
Why uptime monitoring matters
Detect outages before users report them
Without monitoring, you learn about outages from support tickets, social media, or worse — lost revenue. Automated checks detect problems in seconds rather than hours.Measure reliability objectively
Uptime monitoring provides hard data: how many checks passed, what your availability percentage is, and how long incidents lasted. This feeds SLA compliance reports and internal reliability goals.Hold third parties accountable
If your application depends on external APIs or cloud services, monitoring their uptime gives you evidence when their outage impacts your users.Build confidence in deployments
When you deploy changes, monitoring immediately tells you whether the new version is healthy — faster than any log-watching or manual testing.Key concepts
Check frequency
How often the monitor sends a request. Higher frequency (e.g., every 30 seconds) detects problems faster but costs more and can generate noise. Lower frequency (e.g., every 5 minutes) is sufficient for less critical services.Multi-region checks
Running checks from multiple geographic locations (e.g., US East, EU West) distinguishes between global outages and regional network issues. If only one region reports failure, it might be a network path problem rather than a service outage.Assertions
Conditions that define whether a check passes or fails. Beyond “did the server respond,” assertions can verify:- HTTP status code equals 200
- Response time is under 2 seconds
- Response body contains a specific string
- SSL certificate doesn’t expire within 30 days
Incident lifecycle
When checks fail, the monitoring system follows a defined process:- Detection — check fails in one or more regions
- Confirmation — additional checks confirm the failure isn’t transient
- Notification — alert channels (Slack, PagerDuty, email) are triggered
- Resolution — checks start passing again, incident is closed
DevHelm monitoring
DevHelm supports all check types listed above, plus MCP Server monitoring for AI infrastructure. Get started:Create your first monitor
Set up an HTTP monitor in under 5 minutes.
Monitor types
Full reference for all DevHelm monitor types.