Monitoring · Uptime checks

HTTP, ping and TCP.

Three check types, run on a schedule, from as often as your plan allows. Attach one to a service on your status page and the page stops depending on somebody remembering to update it.

Create your status page All monitoring

HTTP and HTTPS

A real request, not a shallow ping.

The most common cause of a status page lying is a check that only proves a load balancer is alive. An HTTP monitor sends the request you specify and judges the response you specify.

Method: The verb the check sends. A health endpoint that only answers POST is still checkable.
Expected status codes: Which responses count as up. Not every healthy endpoint returns 200 — a 201, a 204 or a deliberate 401 can be the correct answer.
Custom request headers: Authorization, API keys, tenant or version headers. Anything the endpoint needs before it will answer honestly.
Request body: Send a payload rather than pinging a route that returns 200 whatever happens. Checking the thing your users actually call is the point.
Follow redirects: On by default. Switch it off when the redirect itself is the contract you want to assert on.
Timeout: Per monitor. A response that never arrives is a failure, and you decide how long never is.

Monitor · POST /v1/health

Operational

Method: POST
Expected status: 200, 204
Interval: 30 sec
Timeout: 10 sec
Follow redirects: Yes
Last response: 142 ms

Request headers

authorization: Bearer •••••••••

x-acme-tenant: acme-prod

accept: application/json

Last 90 days

Each result records whether the response matched, and how long it took. Both figures end up on your status page — the first as the service state and the daily bar, the second as the response time readout.

Beyond HTTP

Two checks for the things a browser cannot reach.

Not everything worth putting on a status page answers a URL.

ICMP ping

An echo request to a host. The right check for anything that does not speak HTTP — a router, a bastion, a box you only need to know is reachable.

Host: edge-01.acme.net
Interval: 60 sec
Last round trip: 18 ms

TCP port

Opens a connection to a host and port. Use it for the things behind your HTTP layer — a database, an SMTP relay, a message broker, an SSH bastion.

Host: db-primary.acme.net
Port: 5432
Last connect: 6 ms

Frequency

How often a check can run.

Your plan sets the floor. You can always check less often than the floor — a WHOIS-style, slow-moving service does not need a check every thirty seconds — but you cannot go below it.

Plan	Fastest interval	Monitors
Free	3 min	25
Starter	60 sec	100
Growth	30 sec	300
Scale	30 sec	1,000

HTTP, ping and TCP monitors all count toward the same total

On the page

A service on your page is a monitor you attached to it.

There is no second copy of the truth. The row your customers read and the check that produced it are the same object.

01
Create the monitor
Point it at the endpoint, host or port, set the interval and the pass conditions, and let it collect results.
02
Attach it to a page
The monitors you attach to a status page become the services listed on it. Nothing is copied across — the service row and the check are the same object.
03
The page reads it out
State, 30-day uptime to two decimal places, latest response time, and 90 daily bars — each bar carrying that day's uptime percentage, average response time and check count on hover.
04
Failures publish themselves
Three consecutive failures on an attached monitor opens an incident at your page's default impact and seeds an automatically-detected first update. The first successful check posts a recovery update and resolves it. Until an incident is declared, a down monitor raises the automatic outage banner on its own.

status.acme.com

Acme Status

Uptime · 30 days

API

99.98%

Web app

99.94%

Webhooks

99.89%

Elevated webhook delivery failures

02:14 UTC — Opened automatically after 3 consecutive failed checks.

Uptime bars, response times and incident history are each a per-page toggle — attach the monitor and still decide how much of it your visitors see.

How automatic incidents work

Two things to know

Where uptime checks stop, today.

Both of these are things a reader would reasonably assume. Neither is true yet, so both are here rather than in the small print.

Uptime alerts · building now

The six notification channels are built, tested and in production — but the only thing that currently triggers them is a Watch Owl server-metric alert rule. A failing HTTP, ping or TCP check opens an incident on your status page and notifies nobody. This is the single biggest gap in the product and it is what we are working on right now.

Multi-region checks · up next

Fully built and deployed — monitors carry a region list, nodes are assigned per region, and the scheduler already dispatches per region. It is capped at one region per monitor on every plan until we have enough node capacity in more locations to promise it.

The full roadmap, including what is not built