Skip to main content
High availability → Uptime watches whether your services are up, keeps their uptime per day, records incidents and publishes a public status page anyone can open without signing in. The page has three tabs: Monitors (with the incidents still open above them), Incident history and Public status page. New incident is at the top, whichever tab is open. The open tab is part of the page’s address (?tab=history, for example).
Not the same as Status pages: those replace a site with a maintenance, moved or blocked page. Uptime only watches and reports; it never changes what visitors of a site get.

Monitors

A monitor checks one of two things: Monitors watch your routes only: the URL’s hostname must be one a route of your proxies serves. The dialog lists the proxied names; other sites and addresses are refused. Each monitor has an interval (20 seconds to an hour, 60 seconds by default), a timeout and how many failed checks in a row make it down (2 by default). A single failure shows it degraded until the next check; a URL monitor can also count answers slower than a limit as degraded. Paused monitors aren’t checked and keep their history. The list shows each monitor’s state and since when, 90 days of uptime bars (30 on a phone; hover a bar for that day), its uptime over 30 days, and a line of its last 60 checks’ response times with failed checks in red. Open a monitor for its uptime over 24 hours, 7, 30 and 90 days, its last check and error. Check now runs one check and shows what it saw without keeping it; Test in the dialog does the same before you save. Uptime is the share of checks the monitor wasn’t down (degraded counts as up), the same way over 24 hours (the checks of the last 24 hours, by the hour) as over 7, 30 and 90 days (the days with checks). A monitor without checks in that time shows —, not 0%, and so does a new one without any checks of its own yet (on the public status page too, never 100%). For a monitor younger than the window, its uptime is since the day it was made, and the public page says so (“100% uptime since 28 Oct”), as does the Uptime page (since 28 Oct under the 30-day number, and in the monitor’s details). Days follow the display time zone and are kept 400 days.
Checks run on one server: the cluster’s leader, so each runs once and alerts go out once. A DNZ secondary following a primary checks nothing; monitors are the primary’s, and the secondary is read-only for them. URL monitors are requested from that server, so the URL must be reachable from there.

Routes under attack protection

Under attack and the waiting room would stop DNZ’s own checks (a check runs no script). DNZ signs its checks for each DNZ Proxy serving the hostname, and the nodes let them through those two; sign-in, the WAF and the firewall still apply.

Checks from several places

From one place, a problem on DNZ’s own network reads as an outage. A URL monitor can also be checked from DNZ Proxy nodes elsewhere (the dialog’s Where it checks from): it is then down only when most places agree, and each place’s response time shows. A place is a node’s name or a region, a label on a node: start it with --region jakarta (DNZ_PROXY_REGION), or set it in the node’s dialog. A region is one place, however many nodes are in it. DNZ itself is always one of the places. The incident and the alert say so (down from 2 of 3 places: DNZ: answered 502; jakarta: no answer within 10 s), the monitor’s details show each place with its last checks, and the 24 h, 30 and 90 day numbers count the monitor as a whole, as for any other. Only the cluster’s leader schedules. It asks each place’s node over that node’s stream, and a node’s check carries the same signature as DNZ’s, so Under attack and the waiting room don’t stop it. A place that can’t be asked doesn’t count, either way, and says why: a node older than this version, one not connected to the leader, a name no node goes by any more. A DNZ Proxy upstream monitor has no places: it already reads what every node reports. The public status page shows nothing new: no places, numbers per place or node names.

A group of routes

Rather than one monitor per route, watch a whole group from Proxy → Routes: Add monitor → A group of routes, pick the group and the path requested on each hostname (/ or /health). DNZ keeps a monitor per hostname of the group’s routes, named after it. A route that joins the group gets its monitor within 30 seconds, and one that leaves loses it. Changing the watch (the group’s card above the monitors) changes all of its monitors; Stop watching removes them or keeps them as monitors of their own.

Incidents

When a monitor goes down, DNZ opens an incident (“name unavailable”, status investigating) with what the failing check saw, and resolves it when the monitor is back (“Checks pass again after 4m 10s”). You can post updates to it in between. You can also write incidents yourself, for what monitors can’t see or for planned work: a title, a status (investigating, identified, monitoring, resolved), an impact and the monitors it affects, then updates over time. Each update sets the incident’s status: resolved ends it, another status opens it again. An incident that affects no monitor is about everything, and the page’s overall status shows it. An incident can be kept off the public page. Open incidents show above the monitors on the Monitors tab; those resolved in the last 90 days are on the Incident history tab. Both lists come a page at a time: the monitors with a search and a filter by state (up, degraded, down, unknown, paused), the incident history newest first.

Incidents written afterwards

A power cut takes DNZ down with everything else: its checks can’t see the outage, and nobody can write the incident until it is back. So an incident’s times can be in the past, never in the future: Started (default now), Resolved when you open it as resolved or edit it later, and each update’s time (default now). They go in order: started, then the updates, then resolved. The newest update sets the incident’s status; an update dated before it fills in the timeline and leaves the status as it is. The fields are on the server’s clock, the time zone of Settings → General, shown beside them. When DNZ was off for more than 5 minutes, the Uptime page offers it once it is back: DNZ wasn’t checking from 13:04 to 14:31 — open an incident for it? Open incident fills in both times; Dismiss ends the offer. Where DNZ checked, its checks count. Where it wasn’t checking, an incident you wrote counts for the monitors it names, as the checks they would have made then: That goes into the bars, the 24-hour, 7, 30 and 90-day uptime, the public page (for incidents shown there) and the metrics. Hovering a bar says how many of its checks were filled in. Incidents DNZ opened itself fill nothing, nor does time before a monitor was added.

Scheduled maintenance

Maintenance planned under Proxy → Status pages keeps uptime quiet for the hostnames it covers: a repeating window, or a maintenance status page that is on (also one set on several routes at once).
  • A monitor of such a hostname (an HTTP monitor’s URL host, a service monitor’s hostname) keeps checking and keeping its results, but while the maintenance is on a failed check counts nothing: no failures in a row, no automatic incident, no alert, and nothing in its days or its uptime. Its row says In maintenance until 23:00. A monitor that was already down stays down, with its incident open. A monitor whose checks have all failed in maintenance is still not checked yet and shows — for its uptime, never 100%; a passing check counts, maintenance or not.
  • At each occurrence of a repeating window that covers a monitor, DNZ opens an incident “Scheduled maintenance: name” (impact Maintenance, so those days show as maintenance) and resolves it with “Maintenance finished.” at the end. It is on the public page when the window is set to be and one of its monitors is on the page.
  • The public page lists the next 7 days’ occurrences under Scheduled maintenance.
  • A window with Uptime stays quiet off still shows its maintenance page, but monitors alert as usual.
To take sites down for maintenance, set a status page on their routes rather than turning the routes off: a watched group’s monitors follow its routes that are on, so turning routes off removes their monitors.

The public status page

Turn it on in the Public status page card, on the tab of the same name. It is at http(s)://<your DNZ>/status, its content as JSON at /status.json (its fields, scheduled maintenance included), and on its own hostname if you give one. It shows:
  • your logo and label from Settings → Profile, a title and description
  • the overall status: all systems operational, degraded performance, partial or major outage, under maintenance
  • open incidents with their timeline
  • Scheduled maintenance: the coming 7 days’ occurrences of repeating maintenance that covers a monitor on the page
  • the monitors you put on it, under the public name and group you give them, with their state, uptime bars and uptime
  • past incidents of the last 14 days (1 to 90), under the days that had one (one line when there were none)
Visitors see only what you chose for them: public names, groups, incident titles and the updates you write. Never a monitor’s own name, URL, address, status code or error. The page is one self-contained document (no fonts or scripts from elsewhere; the only outside image is a logo given as an https:// address), so it works over plain http and whatever else is down. It reloads itself every minute and shows times in the visitor’s time zone.

On its own hostname

Give the page a hostname, such as status.example.com, and DNZ answers requests for that name with the page alone: neither the DNZ dashboard nor its API is reachable under it. While the page is on, the proxies’ pages that say a site is down (unreachable, bad gateway, gateway timeout, no server) link to it with a Service status button. Under How visitors reach it, pick one:
  • Through a proxy, set up by DNZ: choose one or more proxies (or All proxies) and DNZ’s own address as they reach it: its IP and the port its web UI listens on, prefilled from Settings → General → Server → Device address. Save with the page on and DNZ makes a route on each proxy (HTTPS, with the redirect from http) and the DNS record, answered through all of them, right away, so the page shows whichever proxy a visitor comes through. Taking a proxy off the list deletes its route; turning the page off deletes them all, and a record that was there before only leaves the proxies. DNZ first checks that the address answers as DNZ and refuses one that doesn’t, such as a proxy’s address or its port 80/443 (its redirect to https would end in “too many redirects”). Never the page’s hostname either, and not localhost unless the proxies run on the same machine. A route a picked proxy already has for the name is left as it is; if it goes somewhere else, the card warns that visitors coming through that proxy won’t get the page. A wildcard route of the proxy (*.example.com) that sends other names elsewhere doesn’t get in the way: the page’s own route goes before it. The card shows the name’s DNS records and routes as they are.
  • I’ll point it at DNZ myself: a DNS record pointing the name straight at DNZ (when DNZ’s HTTP port is 80), or a route on a proxy DNZ doesn’t manage, which must pass the visitor’s hostname on.
Making or deleting the route needs Manage proxies too. If the route or DNS record can’t be made, the page is still saved and the card says why.
Visitors don’t load DNZ: on its own hostname the page may be cached (30 s on DNZ Proxy, whose route DNZ makes with its cache on, 15 s in browsers), and DNZ builds it at most once every 10 seconds.

Alerts

Add the event Uptime to a notification provider. DNZ notifies when a monitor goes down, with what failed, and when it is up again, with how long it was down. Webhooks get the monitor, state, error, status code, response time and incident in details.

Prometheus

The bundled alert rules include DnzUptimeMonitorDown (2 minutes down). See Prometheus.

From the terminal and assistants

dnz uptime does all of this from the terminal (see Uptime CLI); the API has the same. AI assistants connected over MCP can read monitors and incidents with list_uptime_monitors (with the times DNZ wasn’t checking) and list_uptime_incidents, and scheduled maintenance with maintenance_windows (dnz proxy maintenance in the terminal). Reading needs Manage monitoring, Manage proxies or Post incidents; changing needs Manage monitoring. Post incidents (the built-in Helpdesk role) also opens, edits and updates incidents, without touching monitors, the public page or anything else; deleting an incident stays with Manage monitoring. Every change is in the audit log.