Updated 25 October 2026 · By the Upcertain team
How it works
- You give the monitor something to check: a URL, a host, a port or a scheduled job.
- It checks on an interval, such as every 30 seconds or every 5 minutes.
- Each check passes or fails by a rule: the right status code, a phrase on the page, an open port, a valid certificate, a heartbeat that arrived on time.
- When a failure is confirmed, it opens an incident and alerts the people responsible.
- When checks pass again, it records the recovery and the downtime.
Kinds of checks
| Check | Answers |
|---|---|
| HTTP | Does the URL answer with an acceptable status? |
| Keyword | Does the page say what it should, or something it should not? |
| Ping | Is the host reachable? |
| Port | Does a service such as a mail server or database accept connections? |
| SSL certificate | Is the certificate valid, and when does it expire? |
| Heartbeat | Did the scheduled job report in on time? |
Why monitor from outside
Logs and server metrics describe what your server sees. Uptime monitoring describes what a visitor sees: DNS, certificates, the network, the load balancer and the application all have to work for a check to pass. It catches the failures that internal tools are blind to, including the server being completely gone.
What it does not tell you
- Why something failed. A monitor records the symptom, such as an HTTP 503 or a timeout; your logs explain the cause.
- Everything in between checks. A failure shorter than the interval can fall between two checks. See how often to check.
- Every user's experience. A check from one place can pass while users elsewhere have trouble, and the reverse.
- Whether a multi-step flow works. Signing up or paying needs browser-based transaction checks, which are a different kind of tool.
False alarms and how to avoid them
A single failed request is often noise: a dropped packet or a restarting container. Good monitoring confirms a failure before alerting, by checking again a few seconds later or from another location. Without that, teams quickly learn to ignore alerts. See confirmation checks.
Where the alerts go
Email is the baseline. Most teams add the chat tool they work in, such as Slack or Microsoft Teams, and a webhook into their own tools. On-call teams connect a paging service that phones the person on duty.
Status pages: telling customers
Monitoring tells your team. A status page tells your customers, built from the same checks: what is up, what is down, and what happened recently. It saves your support team from answering the same question many times during an outage.
Getting started
- Monitor the page customers use most: the home page, the app's login, the public API.
- Add a keyword check for pages that can fail with status 200.
- Add heartbeats for backups and scheduled jobs.
- Send alerts to the people who can fix things, and confirm failures before anyone is woken.