What Is Uptime Monitoring? How Synthetic Checks Work

Uptime monitoring is the practice of periodically probing your infrastructure from outside your network to confirm it responds correctly, fast enough, and from multiple geographic vantage points. The mechanism behind it is called a synthetic check: a scripted request sent on a schedule that mimics what a real visitor or API client would do, then evaluates the result against pass/fail criteria you define.

Unlike log-based or APM tooling that only sees traffic that actually reaches your servers, synthetic checks generate their own traffic. That means they catch outages even when zero real users are hitting the endpoint at 3 a.m., and they catch DNS, routing, and CDN failures that never touch your application code.

The four core check types

Most monitoring platforms, including ServerInspector's uptime monitoring, build on four primitives. Each measures something different, and picking the wrong one produces false confidence.

HTTP(S) checks

An HTTP check sends a GET or HEAD request to a URL and validates the response. At minimum it checks the status code, but a well-configured check goes further:

curl -o /dev/null -s -w "http_code=%{http_code} time_total=%{time_total}
" https://example.com/health

A production-grade HTTP check should verify:

• Status code is in an expected range (e.g., 200-299, or explicitly 200)
• Response time under a defined threshold (e.g., 2000ms)
• TLS handshake succeeds (see SSL monitoring for certificate-specific checks)
• Optional: response body contains or excludes a keyword

TCP checks

A TCP check simply attempts a socket connection to a host and port, without any application-layer payload. It's the right tool for databases, mail servers, custom protocols, or anything that isn't HTTP.

nc -zv -w 5 db.example.com 5432

TCP checks measure reachability and port availability. They tell you nothing about whether the service behind the port is actually healthy - a database process can be hung while still accepting connections.

Keyword (content) checks

A keyword check is an HTTP check with an added assertion: does the response body contain (or not contain) a specific string? This is critical because a page can return HTTP 200 while displaying "Fatal error" or a maintenance banner - a plain status-code check would report that as "up."

curl -s https://example.com/status | grep -q "All systems operational" && echo OK || echo FAIL

Ping (ICMP) checks

A ping check sends ICMP echo requests to confirm host-level reachability. It's the lowest-layer check available and useful for network infrastructure, but many cloud providers and firewalls block ICMP by default, so a failed ping doesn't always mean a real outage - and a successful ping doesn't mean your web server is running.

Comparison of check types

Regions and why a single vantage point lies

Running a check from one location tells you the service is reachable from that one network path. If your DNS provider, ISP, or a specific CDN edge has a regional issue, a single-region check might report "up" while a meaningful percentage of your real users are down.

Multi-region checks solve this by running the same probe from independent networks - typically spread across North America, Europe, and Asia-Pacific - and applying a consensus rule before firing an alert, such as "alert only if 2 of 3 regions fail." This dramatically cuts false positives caused by transient regional network blips rather than actual outages.

Interval and retry logic

Two settings determine how fast you detect a real incident and how much noise you tolerate:

• Check interval: how often the probe runs (commonly 30s, 1min, 5min). Shorter intervals mean faster detection but more requests against your infrastructure and monitoring quota.
• Retry / confirmation count: how many consecutive failures are required before an alert fires. A single slow response due to a garbage-collection pause shouldn't page anyone; three consecutive failures across retries usually should.

A typical sane configuration:

• Interval: 1 minute
• Retry: 2 (i.e., confirm failure on the 2nd consecutive failed check)
• Retry interval: 30 seconds (faster than the normal interval, to confirm quickly)

This gives you a worst-case detection time of roughly 90 seconds while filtering out one-off blips.

What a check actually measures - and what it doesn't

It's worth being explicit about the boundaries of synthetic uptime monitoring:

• It measures availability from the probe's vantage point, not from every user's ISP.
• It measures response time for a specific request, not full-page load time including JS execution and assets.
• It does not measure business-logic correctness beyond whatever keyword or status assertions you configure.
• It does not replace real user monitoring (RUM) for understanding actual end-user experience - the two are complementary.

Checklist: setting up a solid uptime check

• Choose HTTP for websites/APIs, TCP for raw services, keyword when a wrong page could still return 200
• Enable multi-region checks with a 2-of-3 (or similar) consensus rule
• Set interval based on how fast you need to know (1–5 minutes for most production services)
• Configure retries to avoid alert fatigue from transient blips
• Add a keyword assertion on any page where "200 but broken" is possible
• Pair uptime checks with SSL monitoring and domain expiration monitoring so certificate and registrar issues don't sneak up on you
• Publish results on a status page so stakeholders don't need to ask "is it down for you too?"

FAQ

How is a synthetic check different from a health check endpoint?

A health check endpoint (like /health) is code you write that runs inside your application. A synthetic check is an external probe that calls that endpoint (or any URL) from outside your infrastructure on a schedule. You need both: the endpoint defines what "healthy" means, the synthetic check verifies it's actually reachable from the outside world.

Can uptime monitoring detect a DNS outage?

Yes. Since synthetic HTTP checks resolve the domain before connecting, a broken or expired DNS record will cause the check to fail, typically with a resolution error rather than a timeout - which is a useful signal for triage.

How many regions should I monitor from?

Three is a common baseline for production services: it lets you apply a majority-consensus rule and avoids paging on single-region network flakiness while still detecting genuine multi-region or origin outages quickly.

Does a passing ping check mean my website is up?

No. ICMP reachability only confirms the host responds to network-layer pings; it says nothing about whether your web server process or application is functioning. Use HTTP or keyword checks for web-facing services.

What check interval should I use for a critical payment API?

For services where downtime has direct revenue impact, use the shortest interval your plan and rate limits allow - commonly 30 seconds to 1 minute - combined with tight retry logic and multi-channel alerting.