See a service's uptime and tune its health check

Every service you publish is probed by its own host’s daemon every 30 seconds: is the backend port alive, and (for HTTP) does it really answer. The Console turns those probes into an uptime history you can read at a glance, and lets you tune the HTTP check or turn it off per service. (Since v0.3.0.)

See a service’s uptime

On the Services page, each service row has an Uptime (24h) column: a compact bar of the last 24 hours plus the headline percentage. Each segment is one slice of time, colored by how healthy the service was in that slice - green for up, amber for degraded, red for down, and a hatched slice for “no data yet”.

Click the bar to open the uptime dialog, where you can switch between the last hour, last 24 hours, and last 7 days. The dialog shows the headline uptime for the window, the full bar with a per-segment tooltip (hover a segment for its time range and percentage), a legend, and the service’s current health badge. When the service is a healthy HTTP or TCP backend you also see an approximate probe latency (for example ~120 ms) next to the badge, and each segment’s tooltip includes that slice’s average latency.

A service that has not been sampled yet - just published, or its host has been offline the whole window - shows a dash and sorts to the end of the column. Sort by the column to bring your least-healthy services to the top.

What up, down, and unknown mean

The daemon probes from the machine the service runs on, so the reading reflects what the backend actually does:

• up - the port accepted a connection, and for HTTP the backend answered with a status code the check accepts.
• down - the port refused the connection or timed out, or an HTTP backend answered with a status the check rejects (or did not speak HTTP at all). The tooltip on the current badge says which.
• unknown - UDP services are connectionless, so there is nothing to dial; they read as unknown rather than up or down.
• offline - the host itself was disconnected for that slice, so no probe ran.

Offline and unknown slices do not count against your uptime percentage: it is computed only from slices that were actually up or down.

Get alerted when a service goes down

The Console also notifies you when a published service goes down and again when it recovers, so you do not have to watch the uptime bars. (Since v0.3.0.)

• A down alert fires once a service has been failing for three checks in a row (about three minutes). It arrives as a high-priority notification titled “Service down: app”, with the probe’s failure detail and how long it has been failing.
• A recovery alert fires once the service has answered healthily twice in a row, titled “Service recovered: app”, with how long the outage lasted.

Alerts land in a services notification topic that appears in your Notifications page automatically after the first alert. Route it to Telegram or your phone exactly like any other topic - see Get notified.

A few things keep the alerts quiet and trustworthy:

• A service must be seen healthy once before it can alert. A brand-new export that never came up, a typo’d port, or a service still being wired up will not page you - it has to be observed up at least once to arm.
• A rebooting or disconnected host does not fire. While the host is offline, or the service reads as unknown (a UDP listener, or a service with probing disabled), the streak freezes instead of counting toward a down alert.
• Each outage alerts once. A flapping service that dips and recovers within a couple of checks never reaches the threshold, and a confirmed outage does not re-alert every minute or after a Console restart.

Configure the HTTP health check

By default an HTTP service is healthy when it answers GET / with any parseable response. To check a real health endpoint instead, open a service’s row action menu and choose Health check:

• Request path - the path the daemon requests, for example /healthz. Leave it empty to keep the default /. It must start with /.
• Expected status codes - a comma-separated list of codes or ranges, for example 200,204 or 200-299. Leave it empty to accept any 2xx. Each code is 100-599, and you can mix single codes and ranges.

The dialog shows the effective check currently in force and where it comes from (a Console override, a Docker label, or the daemon’s config), and validates your input before you save. Click Save to store the override; it takes effect on the daemon within a few seconds and the next probe uses it.

To go back to the service’s own default, open the dialog again and choose Reset to app default. That removes the Console override; any check set by a Docker label or the daemon’s config applies again.

Disable probing for a service

Some services have no meaningful liveness check - a batch worker, a UDP listener you monitor elsewhere. Toggle Disable health check in the same dialog to stop probing that service entirely. This works for any protocol, and it is the only setting that applies to TCP and UDP services (the path and codes are HTTP-only). A disabled service stops accruing up/down history.

Notes

• The override is per service, keyed by the host and app name. A daemon that is too old to apply overrides still stores yours; the dialog shows a “daemon update required” hint until the host updates.
• History starts fresh on rename. Uptime is tracked by the service’s target (username/daemon/app), so renaming an app, or moving it to a different host, starts a new history under the new name.
• The daemon is the source of truth. The Console stores your override and ships it to the host, but the host’s daemon runs the probe and reports the result; if the host is offline, the last reading is shown as stale until it reconnects.

For the public HTTPS side of a service, see Expose a port publicly.