Uptime monitoring: HTTP, TCP, DNS and ping checks

Your logs tell you about errors your service reports. They tell you nothing when the service stops answering at all: a crashed process, an expired certificate, a DNS change or a load balancer sending traffic nowhere. For that you need something outside the service asking it, on a schedule, "are you there?".

That is an uptime monitor. This post sets one up in ZipLogger, explains the settings that decide when it pages someone, and says what it does not do yet.

Create a monitor

Open Alerts → Detection → Uptime and click + New uptime monitor. You need the Editor or Admin role. The monitor belongs to the environment you are viewing.

Pick a Check:

Then set Check every and Timeout (s). The timeout is 2 to 60 seconds and must be shorter than the interval. A timeout counts as a failed check.

Two things surprise people:

• Redirects are not followed unless you ask. If http://example.com answers 301 to send people to https://, that is the status the check sees. Monitor the final URL, put 301 in Expected status if the redirect is what you want to verify, or tick Follow redirects (up to 5) under Advanced. Each hop is checked against the same address rules as the first URL, so a redirect to a private address is a failed check, never a request.
• A keyword check is the better health check for many pages. A broken deploy often still answers 200 with an error page. Looking for a word that only appears when the page works, such as the name of your sign-in button, catches that.

Advanced: requests and thresholds

The form's Advanced section holds the settings most monitors never need.

For HTTP and keyword checks, under Request:

• Headers, up to 20, for example an API key a health endpoint expects. Header values are stored encrypted and never shown again. When you edit the monitor, leave a value empty to keep the stored one.
• Body and Content type for POST, PUT, PATCH and DELETE, up to 10,000 characters.
• Basic auth user and Basic auth password. The password is stored encrypted the same way.

Under Thresholds:

• Slower than (ms) fails: a response slower than this is a failed check, even with the right status. Empty means no limit, so a slow answer within the timeout counts as up.
• Passes before up (1 to 10, default 1): once a location is failing, how many passing checks in a row it needs before it counts as up again. This stops an incident from closing on one lucky check and reopening a minute later.
• Domain expiry warning (days): covered below.

When it pages someone

A single failed check should not wake anyone. Two settings decide what counts as down:

• Failures before down (1 to 10, default 2) is how many failed checks in a row make one location failing. With 2, one dropped packet is absorbed.
• Confirm from is how many failing locations make the monitor down. It only matters with more than one location (below).

When the monitor goes down, ZipLogger opens one incident with the monitor's Severity (critical by default) and Service. The first round of checks that is no longer down resolves it. The incident names the target, the check and the failing locations, and links back to the monitor. If you switch a monitor off or delete it while it is down, its incident is resolved too, since no later check would do it.

Uptime monitors have no channel list of their own. They reach people through the escalation policy you choose in Page through, and other tools through your destinations (PagerDuty, Opsgenie, Slack and others) that match the incident's severity and service. If you set neither, the incident is still recorded, and its timeline says nobody was notified. Set one before you rely on the monitor.

Locations, including your own network

ZipLogger (Europe) checks from ZipLogger's own servers in Europe, so the target must be public. A URL or host that resolves to a private, loopback or cloud metadata address is refused when you save, and again at every check, so a later DNS change cannot turn a monitor into a probe of ZipLogger's network.

To check something that is not on the internet, such as an internal admin tool or a database port, add a private agent. It is the same container that runs browser automations inside your network, and it pulls work outbound over HTTPS, so you open no inbound ports. A monitor whose locations are all private agents may target private addresses.

The agent image published today (0.1.0, also tagged latest) was built before uptime checks existed. Private locations run uptime checks once a newer agent image is published.

With several locations, Confirm from pays off. With three locations and a confirmation of 2, one location with a bad network path never pages anyone, and a real outage still does.

ZipLogger runs its public checks from Europe only. That is a decision, not a gap waiting to be filled: there is no choice of public regions. If you need checks from other places, run private agents there and confirm across them.

Certificates and domain expiry

On https targets every check also reads the TLS certificate's expiry date. Certificate warning (days) (14 by default, up to 90, 0 turns it off) opens a separate incident when the certificate expires within that many days. It is medium severity, and high within the last 3 days. It resolves on its own when a later check sees the renewed certificate.

A certificate that is already invalid, such as an expired one or one for the wrong host name, fails the check itself, so it shows up as down rather than as a warning.

Domain expiry warning (days) (0 to 120, off by default) looks up the registration of the target's domain once a day through RDAP. It opens a separate incident when the domain expires within that many days, and resolves it when a later lookup sees the renewal. The monitor page shows the registration's expiry date.

History and uptime figures

The monitor list shows each monitor's state, its uptime over the last 24 hours, 7 days and 30 days, and its last response time. A monitor's own page shows 90 day bars, a response time chart with one line per location, each location's latest result, and the latest checks with their errors. A failed HTTP or keyword check keeps a snippet of the response: the status line, a few headers and the start of the body. Click response next to the check to see what the server sent.

Every check is kept for 30 days. Daily figures are kept for 400 days. Daily uptime is up checks divided by up plus down checks. A day with no checks is no data, never 100%, so a monitor that was paused does not quietly look perfect.

Plan limits

Checks are not counted or billed one by one. Creating a monitor past your plan's number, or asking for a faster interval, is refused with 403 and the code plan_limit.

From a script

Everything in the form is in the API. Create a personal access token with Read and write under Profile → API tokens, then:

curl -X POST https://app.ziplogger.ai/api/v1/uptime/monitors \
  -H "Authorization: Bearer zlp_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Checkout API",
    "kind": "keyword",
    "target": "https://shop.example.com/health",
    "keyword": "ok",
    "keywordAbsent": false,
    "expectedStatus": "200-299",
    "timeoutSeconds": 10,
    "intervalSeconds": 60,
    "regions": [],
    "failureThreshold": 2,
    "confirmationThreshold": 1,
    "sslExpiryWarnDays": 14,
    "enabled": true,
    "severity": "critical"
  }'

An empty regions list means ZipLogger's own location in Europe. GET /api/v1/uptime/limits shows how many monitors your plan allows and how many you use. A validation error answers 400 with the field it is about. The API never returns header values or the basic auth password: a monitor answers with requestHeaderNames and hasBasicAuthPassword instead. GET /api/v1/uptime/monitors/{id}/latency?hours=24 returns the response time series the chart draws.

What it does not do yet

• No UDP checks.
• No multi-step API checks, such as signing in and then calling an endpoint with the token. A browser automation can do that.

Next step

Uptime monitors also drive the components of a public status page for your own customers. The status page post sets one up. The full reference is in the uptime monitor docs.