> ## Documentation Index > Fetch the complete documentation index at: https://docs.dnzwithazee.com/llms.txt > Use this file to discover all available pages before exploring further. # Uptime and public status page > Watch whether your services are up, keep their uptime per day, write incidents and publish a public status page like statuspage.io. **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). > [!NOTE] > > Not the same as [Status pages](https://docs.dnzwithazee.com/proxy/status-pages.md): 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: | Kind | What it checks | Good for | | - | - | - | | **A URL** | DNZ requests it: the status code (200–399 passes unless you list codes such as `200,301-302`), optionally a keyword the answer must contain, and how long the answer took. Redirects are followed. `GET` or `HEAD`, and "accept any certificate" for self-signed servers. | A route of Traefik, Caddy or DNZ Proxy, by its hostname | | **A DNZ Proxy service** | The servers behind a hostname a DNZ Proxy route serves, from the upstream health the nodes already report every 5 seconds (for a Split, the servers of the upstreams it splits over; for a Fallback, its main and fallback upstreams; for a Mirror, its main upstream). Up while every server is healthy, degraded while some are, down when none is or no node reported in the last 30 seconds. Nothing extra is sent. | Proxied services, server by server. Turn on the route's health check for the clearest answer | 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. > [!NOTE] > > 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. | State | When, among the places that answered | | - | - | | **Down** | More than half of the places failed *Down after* checks in a row (2 by default) | | **Degraded** | Some places fail or are slower than the limit, but not more than half | | **Up** | All of them pass | 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. | Impact | The affected monitors show on the public page as | | - | - | | Minor | Degraded performance | | Major | Partial outage | | Critical | Major outage | | Maintenance | Under maintenance | 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: | Impact | Counts as | | - | - | | Critical, Major | Down | | Minor | Degraded (up in the percentages) | | Maintenance | Nothing (the bars show maintenance) | 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](https://docs.dnzwithazee.com/proxy/status-pages.md#scheduled-maintenance), or a **maintenance** [status page](https://docs.dnzwithazee.com/proxy/status-pages.md) that is on (also one set on [several routes at once](https://docs.dnzwithazee.com/proxy/overview.md#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. > [!TIP] > > To take sites down for maintenance, set a status page on their routes rather than turning the > routes off: a [watched group](#a-group-of-routes)'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):///status`, its content as JSON at `/status.json` ([its fields](https://docs.dnzwithazee.com/api/uptime.md#the-page-as-json), 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](#scheduled-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. ```bash theme={null} dnz uptime page set --on --hostname status.example.com --proxy edge,edge-2 --dnz-address http://10.0.0.53:8080 ``` 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. > [!NOTE] > > 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](https://docs.dnzwithazee.com/integrations/notifications.md). 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 | Metric | Labels | Meaning | | - | - | - | | `dnz_uptime_up` | `monitor`, `kind` | 1 while up (or only degraded), 0 while down | | `dnz_uptime_status` | `monitor`, `state` | 1 for the state it is in | | `dnz_uptime_response_seconds` | `monitor` | How long its last check took (URL monitors) | | `dnz_uptime_ratio_30d` | `monitor` | Share of the last 30 days' checks it was up | | `dnz_uptime_last_check_timestamp_seconds` | `monitor` | When it was last checked | | `dnz_uptime_open_incidents` | | Incidents not resolved yet | The bundled alert rules include `DnzUptimeMonitorDown` (2 minutes down). See [Prometheus](https://docs.dnzwithazee.com/dashboard/prometheus.md). ## From the terminal and assistants `dnz uptime` does all of this from the terminal (see [Uptime CLI](https://docs.dnzwithazee.com/cli/uptime.md)); the [API](https://docs.dnzwithazee.com/api/uptime.md) has the same. AI assistants connected over [MCP](https://docs.dnzwithazee.com/integrations/ai-assistants.md) 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](https://docs.dnzwithazee.com/admin/audit-log.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.