What is the difference between uptime monitoring and a health check?

A health check is an endpoint your service exposes. Uptime monitoring is the outside process that calls it, or any other URL, port or record, on a schedule from somewhere else, decides when a failure is real, and alerts you.

How often should an uptime monitor check?

Often enough that the check interval is a small fraction of the downtime you can tolerate. Every minute suits most production APIs; every few minutes is fine for side projects; 30 seconds is for services with very strict uptime targets.

Do I need to monitor from more than one region?

For anything users reach from more than one place, yes. A check from a single location cannot tell an outage of your service from a network fault between that location and you, so it either misses regional outages or pages you for problems that are not yours.

/ uptime-monitoring

What is uptime monitoring? A developer's guide

Uptime monitoring checks your sites, APIs and jobs from outside on a schedule and alerts you when they stop answering. How checks, regions and alerts work.

Updated 2026-10-31

Uptime monitoring is the practice of checking a website, API, server or scheduled job from the outside, on a fixed schedule, and alerting someone when it stops answering the way it should. A monitor sends a request, opens a connection or resolves a record every 30 seconds to a few minutes, decides whether a failure is real, and routes an alert when it is. Fettle is uptime monitoring for developers: HTTP, ping, TCP, DNS and SSL checks plus heartbeat and cron monitoring, probes from three regions, alerts with a structured cause, status pages, and a REST API and MCP server on every plan. This guide walks through how each part works and what to set it to. The deeper guides take one part at a time.

What does uptime monitoring not do?

Uptime monitoring answers one question from outside your system: does it respond correctly, right now, from where your users are? It does not look inside your code, profile slow functions, replay what a visitor did on the page, or store what your application writes about itself. An uptime monitor is the alarm, not the investigation.

That narrow scope is the point. An external check fails when your service fails, whatever the cause: a crashed process, an expired certificate, a DNS change gone wrong, a cloud region having a bad day. Tools that live inside your stack go dark with it. The two complement each other, and when something is down, the uptime monitor is usually the one that tells you first.

It also does not prove correctness. A check confirms that a URL returned the status code and the text you expected; it does not confirm that a checkout flow works end to end or that the data behind the page is right. Pick checks that fail when the thing you care about is broken, and keep your tests and data checks for the rest.

Which checks does an uptime monitor run?

Most failures show up in one of a handful of probes: an HTTP request, a TLS certificate, a TCP port, a DNS record or an ICMP ping. Each answers a different question, and a service often deserves more than one. Jobs that run on a schedule need the opposite model, a heartbeat, because they have nothing to probe.

HTTP and keyword checks are the default for websites and APIs. Fettle sends a GET, HEAD, POST, PUT, PATCH or DELETE request with up to 20 custom headers and an optional request body, and passes the check only when the status code is one you listed. Add a keyword and the check also fails unless that exact, case-sensitive text appears in the first 1 MiB of the response, which catches the error page served with a 200. The API health check guide covers what a good health endpoint returns and how to probe one behind authentication. A monitor created through the API looks like this:

curl -s -X POST https://api.fettle.sh/v1/monitors \
  -H "Authorization: Bearer fettle_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "API health",
        "type": "HTTP",
        "target": "https://www.example.com/healthz",
        "interval_seconds": 300,
        "timeout_seconds": 10,
        "regions": ["eu-central"],
        "confirmation_threshold": 2,
        "config": {
          "method": "GET",
          "expected_status_codes": [200],
          "keyword": "healthy"
        }
      }'

SSL checks open a TLS connection, verify the certificate chain and hostname, and warn you a set number of days before expiry, anywhere from 1 to 365. Automated renewal fails quietly, which is why this check exists; the SSL expiry guide explains the usual failure modes, and the free SSL checker reads a certificate once by hand.

TCP checks test that a port accepts connections, for databases, mail servers, game servers and anything else that does not speak HTTP. They also run the other way: list up to 20 ports that must stay closed and Fettle alerts if one opens, a cheap guard against an accidentally exposed database. DNS checks query an A, AAAA, CNAME, MX, TXT or NS record and can require a specific value in the answer, so a hijacked or fat-fingered record becomes an incident instead of a mystery. Both are covered in the TCP port and DNS monitoring guide. Ping checks send ICMP echoes to a host; a host that answers some of them but not all shows as degraded, one that answers none as down.

Heartbeats cover the jobs that run rather than answer: cron jobs, queue workers, backups, CI schedules. Instead of Fettle calling the job, the job calls a ping URL when it succeeds, and Fettle opens an incident when the ping does not arrive within the period plus a grace window you set. A job can also report /start when it begins and /fail when it catches its own error, which alerts at once. Each plan includes heartbeats: 3 on Free, 20 on Plus, 50 on Pro and 150 on Max. The cron job guide and the GitHub Actions guide show the setup line by line, and heartbeat monitoring lists what is included.

How often should you check?

The check interval decides how fast you hear about an outage and how short an outage you can see at all. A monitor checking every five minutes can stay silent through a four-minute outage. As a rule, pick an interval that is a small fraction of the downtime you are willing to absorb in a month.

Fettle's intervals run from 30 seconds to a day, bounded by plan: the shortest interval is every 3 minutes on Free, every minute on Plus and Pro and every 30 seconds on Max for up to 50 monitors (every minute for the rest). The free plan covers 20 monitors, checked every 3 minutes from 1 region. A reasonable starting point:

Production APIs and checkout paths: every minute. You hear about an outage within a couple of minutes, once confirmation is counted, and the monthly figure means something at 99.9%.
Marketing sites, docs, side projects: every few minutes. Faster checks buy little when nobody is paged at night anyway.
Services with a strict uptime target: 30 seconds, from every region you can, because the interval sets a floor on what you can measure. The 99.9% uptime guide works through the numbers.

Each check also has a timeout, from 1 to 120 seconds. Set it a little above the slowest response you consider healthy; a request that takes longer counts as a failure.

Why does checking from one region lie?

A check from one place cannot tell your outage from the network's. If the route between that probe and your server breaks, the monitor reports you down while your users are fine. If your service fails only in one part of the world, a probe elsewhere reports you up. Checking from several regions and deciding together removes both errors.

Fettle checks from USA, Europe and Asia, and every selected region checks the monitor on every interval. The decision is unanimous: a monitor goes down, opens an incident and sends an alert only when every region that reported recently sees it failing, for as many consecutive rounds as the monitor asks for. A failure confirmed in some regions but not others marks the monitor as degraded, visible in the dashboard but not paged. A down monitor stays down through a partial recovery and comes back up on the first round where every region sees it answer, so a service that recovers in only some regions does not open a second incident.

Multi-region checks start on the Plus plan, which allows up to 2 regions per monitor; the free plan checks from one region. SSL, DNS and port-list TCP monitors use a single region: a certificate is the same from everywhere, and GeoDNS can make a correct record differ by region, which would raise false incidents. The multi-region monitoring guide explains the rule in detail, and the free multi-region check probes a URL from every region once, without an account.

How do you keep alerts from becoming noise?

An alert nobody trusts is worse than no alert, because people learn to ignore it. Most false alarms come from single failed checks: a dropped packet, a slow garbage-collection pause, one bad route. Requiring a failure to repeat before anyone is paged removes nearly all of them at the cost of a minute or two of delay.

In Fettle that is the confirmation threshold, set per monitor from 1 to 10 consecutive failed rounds. Combined with the unanimity rule above, a monitor only alerts when the failure is both repeated and seen from everywhere it is checked. Every incident then carries a structured cause, such as a timeout, a DNS failure, an invalid certificate, a 5xx response or a missing keyword, so the alert says what broke as well as that something did.

Tune the threshold to the cost of a late alert. A threshold of 1 pages on the first failed round; 2 or 3 suits most production services; a higher value fits endpoints you know to be noisy and can afford to hear about later.

Where should alerts go?

Send alerts where your team already looks when something breaks: a chat channel for daytime incidents, something that wakes a phone for production. Then decide how often the same incident may repeat, and how someone tells the rest of the team they are on it, so one outage does not turn into fifty messages.

Fettle sends alerts by email and Telegram on every plan, and by webhook, Slack and Discord from the Plus plan. Each monitor alerts either every verified channel or the ones you pick for it. The alerts guide shows how to wire each one, and the webhook docs describe the payload.

Three settings control repetition:

Notification cooldown (60 seconds to 24 hours, per monitor) stops the same incident from sending its down alert twice inside that window. Recovery alerts are never held back by it.
Renotification, from the Plus plan, repeats the alert for an incident that is still open and unacknowledged, at an interval and up to a count set by your plan.
Acknowledge marks an incident as owned. Repeat alerts stop; the recovery alert still goes out when the service comes back.

What about planned downtime?

A deploy, a database migration or a host reboot will fail checks, and nobody needs to be paged for work they scheduled. A maintenance window tells the monitor in advance: checks keep running and results are recorded, but no incident opens and no alert goes out until the window ends.

Fettle's maintenance windows can cover a whole organization or specific monitors, run once or repeat on a schedule such as every week or the last Friday of the month, and follow your organization's time zone. They are available from the Pro plan. Time inside a window counts as up, and a status page shows the affected components as under maintenance. Prefer a window to pausing a monitor: a paused monitor stops checking, so you also lose the signal that the deploy went wrong. The maintenance windows guide covers recurring schedules and the pitfalls of each approach.

Do you need a status page?

If anyone outside your team depends on your service, yes. A status page answers "is it just me?" before the question reaches your inbox, and during an outage it is the one place to post updates instead of answering the same question in five channels.

Every Fettle plan includes status pages, 1 on Free, 1 on Plus, 3 on Pro and 10 on Max. Components on a page are backed by monitors, so their state updates itself, and you post incidents and updates by hand when you have something to say. Visitors can subscribe to updates by email from the Plus plan, and the Max plan removes Fettle's branding. For a lighter signal, an uptime badge puts a monitor's live status or uptime into a README.

What does an uptime percentage mean?

An uptime percentage is the share of a period your service was up. 99.9% allows 43 minutes 12 seconds of downtime in a 30-day month; 99.99% allows just over four minutes. The figure is only as good as its definition: what counts as down, which time counts at all, and how often the monitor looked.

Fettle computes it from incidents: one minus confirmed downtime over the time the monitor was actually checked. Unconfirmed blips and degraded periods do not count as downtime, paused time is left out, and maintenance counts as up. The 99.9% uptime guide lays out the budget for every common target and why an uptime figure is not an SLA, and the uptime calculator converts any target into downtime per day, week, month and year.

Can an AI agent run your monitoring?

Yes, through MCP. An agent such as Claude or Codex, or any MCP client, can create and update monitors, read incidents and their causes, run a check on demand and schedule maintenance windows, using the same API key as the REST API. The agent does the clicking; you review what it set up.

The Model Context Protocol is an open standard for connecting AI applications to external systems. Fettle's MCP server is available on every plan, including free, either hosted at https://api.fettle.sh/mcp with nothing to install or as the fettle-mcp npm package. Prompts that work well:

"Create an HTTP monitor for https://www.example.com/healthz from every region my plan allows, and tell me which interval you chose."
"Which monitors are down right now, and what caused each incident?"
"Schedule a maintenance window for the API monitors this Saturday from 02:00 to 03:00."

Set up the MCP server takes a few minutes. The AI agents guide shows a full session, and monitoring an MCP server covers the reverse case: watching the MCP servers your agents depend on.

Where should you start?

Start with the one thing whose outage would hurt most, usually the main API or the sign-in page, and add an HTTP monitor with a keyword. Then add an SSL check for each domain, a heartbeat for each job you would not notice failing, and a status page once anyone outside the team depends on you.

If you run on a specific platform, the use cases go step by step: Vercel, Railway, Fly.io and Supabase. Comparing tools first? Fettle vs other uptime monitoring tools puts the numbers side by side, with pages for Uptime Kuma and Pingdom alternatives. Plans and limits are on the pricing page, and the quickstart gets a first monitor running from the API.

Questions

What is the difference between uptime monitoring and a health check?: A health check is an endpoint your service exposes. Uptime monitoring is the outside process that calls it, or any other URL, port or record, on a schedule from somewhere else, decides when a failure is real, and alerts you.
How often should an uptime monitor check?: Often enough that the check interval is a small fraction of the downtime you can tolerate. Every minute suits most production APIs; every few minutes is fine for side projects; 30 seconds is for services with very strict uptime targets.
Do I need to monitor from more than one region?: For anything users reach from more than one place, yes. A check from a single location cannot tell an outage of your service from a network fault between that location and you, so it either misses regional outages or pages you for problems that are not yours.

Start monitoring in a minute

The free plan checks up to 20 monitors as often as every 3 minutes from 1 region, and emails you when one breaks. See pricing for the paid intervals, or follow the quickstart to do it from the API.