What is uptime monitoring? A practical guide

Uptime monitoring is a service outside your infrastructure that keeps asking one question about your website, API or server — is it working right now? — and tells you the moment the answer changes. It's the first line of monitoring most teams set up, because the alternative is finding out from a customer.

This guide covers what a good uptime check actually tests, how often to run it, how to avoid false alarms, and what to do when something really is down.

What an uptime check tests

The simplest check sends an HTTP request to a URL and looks at the status code: a 200 is up, a 500 or a timeout is down. That catches a lot, but not everything. A page can return 200 and still be broken — an empty product list, an error message rendered as a normal page, a login wall where content should be.

That's why most monitoring tools, Zharp included, offer more than one kind of check:

• Website and API checks — status code, response time, and optionally a keyword that must (or must not) appear in the body.
• Ping and port checks — is the host reachable, is the database or mail port open.
• SSL certificate checks — when does the certificate expire, is the chain trusted. (See why certificates still expire.)
• Cron job checks — the job calls a URL when it finishes; silence means it didn't run. (See cron job monitoring.)
• User journeys — a real browser logs in, clicks through and checks the result, for flows a single request can't cover.

Start with the one or two URLs that matter most — your home page and your API's health endpoint — then add checks for whatever has broken before.

How often to check

Check frequency is a trade-off between how fast you find out and how much noise you can tolerate. Every five minutes is enough for most marketing sites and internal tools. Customer-facing APIs and checkout flows deserve one minute or less. Zharp's Free plan checks every five minutes; paid plans go down to every 30 seconds.

Faster isn't automatically better: a 30-second check on a page that changes slowly mostly produces data. Match the interval to how quickly you'd act on it.

Why one location isn't enough

A single checker can be wrong. Its own network has a bad minute, a route between it and your server flaps, a DNS resolver in one country lags. If that one checker decides you're down, you get paged for a problem your users never saw.

Checking from several regions fixes that. Zharp checks from four — Europe, North America, Asia and Australia — and only marks a monitor down when more than half of its regions agree. With four regions, that means three of them. A blip in one region shows up in the check history, but it doesn't wake anyone.

Confirmation and recovery periods

Even with several regions, a service can stutter for a few seconds during a deploy. A confirmation period says how long a failure must last before it counts — say one minute — and a recovery period says how long it must stay healthy before the incident closes. Together they turn a flapping service into one incident instead of six.

Who gets told, and how

An alert nobody sees is the same as no alert. Decide up front:

• Where alerts go — email and push for everyone, plus Slack, Discord, Telegram, PagerDuty or a webhook for the team channel.
• Who is on call — one person at a time, rotating, so the alert reaches someone awake and responsible. (See on-call without per-seat pricing.)
• What happens if nobody answers — escalate to the next person, or the whole team, after a few minutes.

Tell your users, too

When something is down, your users are asking the same question you are. A public status page answers it before they open a support ticket: what's affected, what you're doing, when it was fixed. Zharp's own runs on Zharp, at zharp.io/status.

Getting started

Zharp's Free plan includes 25 monitors of every type, checks from four regions, alerts to every integration and a status page — no card needed. Create a monitor in a couple of minutes, point it at your most important URL, and you'll know before your customers do.