Skip to content
DedNets Docsv0.14.3

Monitor a URL or endpoint with an uptime check

An uptime monitor actively probes a target on a schedule and records whether it answered. Use it to check that a website, API or TCP service is up. It is the mirror image of a watchdog: a watchdog waits to be pinged by a job, while an uptime monitor reaches out and checks. (Monitors since v0.4.5; daemon-origin probing, the Console page and the MCP tools since v0.5.0; the outage log since v0.7.1.)

Create a monitor

Section titled “Create a monitor”

Open Uptime in the Console (under Applications) and choose New monitor.

  • Name - a short identifier (letters, digits, hyphens, underscores).
  • Group (optional, since v0.6.2) - a label such as homelab or a customer name. Monitors sharing it are listed together. Leave it empty for an ungrouped monitor.
  • Probe from - where the check runs:
    • DedNets edge probes from our edge over verified TLS. It can only reach public targets: private, loopback and link-local addresses are refused.
    • One of your daemons probes from a host you own, so it can reach anything that host can - including private services inside your network.
  • Type - HTTP to probe a URL, or TCP to open a host:port.
  • Target - the URL (https://example.com/health) for HTTP, or host:port (db.example.com:5432) for TCP.
  • Interval - how often to probe, between 30 seconds and 1 hour.

For an HTTP monitor you can also require:

  • Status codes - which HTTP codes count as up, e.g. 200 or 200-299,301. Leave it empty to accept any response the server returns.
  • Header checks - up to five assertions on the response headers, each a header name plus an operator (exists, equals or contains) and, for the last two, a value. Values are compared case-insensitively.

Read the results

Section titled “Read the results”

Each monitor shows a live state and a 24-hour uptime strip:

  • up - the last probe succeeded.
  • down - the last probe failed a check or could not connect. The row shows the exact reason (for example HTTP 503 Service Unavailable (want 200-299) or a header that did not match).
  • unknown - no probe has completed yet, or the target could not be probed.
  • offline - the daemon running a daemon-origin probe is offline.

Open a monitor for the window tabs (hour / day / week), the availability strip, and the last-check detail. A daemon-origin monitor’s current state is read from its availability history rather than the row badge.

When a monitor goes down, DedNets alerts your account through the uptime notification topic (the same delivery as watchdogs and service health). Pause a monitor for planned maintenance to suppress probing and alerts without losing its history.

See every outage, and why

Section titled “See every outage, and why”

Open a monitor and scroll to Outages for the list of everything that failed, newest first. Each entry gives you the start time, how long it lasted, how many checks failed, and the reason the first failing check reported, for example HTTP 502 · Bad Gateway or dial tcp: i/o timeout. Load more walks further back; the log is kept for 90 days.

Each incident is labelled one of:

  • confirmed - it failed enough consecutive checks to alert you, and you got a notification.
  • blip - a shorter run that recovered before reaching the alert threshold. Nobody was notified.
  • ongoing - it has not recovered yet.

That split answers the most common surprise: uptime below 100% with no alert in your inbox. DedNets only alerts after three consecutive failed checks, so a target that fails one check and recovers costs you availability without ever paging. If a monitor keeps doing that, the Outages list says so directly, and each row is a single flaky moment you can go and look at.

Every start time is also a plain unix timestamp in the API, CLI and MCP output, so you can paste it straight into a metrics query and line an outage up against your own dashboards. (Since v0.7.1.)

Section titled “Group related monitors”

Give a monitor a group - any label such as homelab, public, or a customer name - and the Console lists every monitor sharing that label together, in one collapsible section. The header shows how many monitors it holds and a single badge for the worst state inside, so one glance at a collapsed group tells you whether anything in it is down. Groups are listed alphabetically, and monitors without one come last, under Ungrouped. Click a header to fold a group away.

The Group field sits right under the name in the create and edit dialogs and suggests the groups you already use, so the names stay consistent. It is optional: leave it empty and nothing changes - if none of your monitors have a group, the list looks exactly as it always did. Clearing the field on an existing monitor moves it back to Ungrouped. Group names take the same characters as monitor names (letters, digits, - and _, up to 64 characters), and a group needs no setting up: it exists as soon as a monitor names it and disappears when the last one leaves. (Since v0.6.2.)

Drive it from an agent or the API

Section titled “Drive it from an agent or the API”

From the command line:

Terminal window
dednetsctl uptime list                 # your monitors, with their state
dednetsctl uptime outages lynx         # that monitor's incidents, newest first
dednetsctl uptime outages lynx -json   # the same, with the full failure reasons

START in the table is unix seconds, ready to paste into a metrics query. (Since v0.7.1.)

The whole lifecycle is there too, so a monitor can be declared next to the thing it watches:

Terminal window
dednetsctl uptime create -name api-health \
  -target https://api.example.com/health -group prod -codes 200
dednetsctl uptime update api-health -interval 120   # only what you pass changes
dednetsctl uptime pause api-health                  # maintenance; history kept
dednetsctl uptime resume api-health
dednetsctl uptime rm api-health                     # monitor and history gone

-kind defaults to http (tcp opens a host:port instead), -origin defaults to edge (-origin daemon -daemon vm1 probes from your own host, the way a private target gets a monitor), and -interval defaults to 60 seconds within a 30-3600 range. On update, -group "" ungroups the monitor and -codes "" accepts any parseable response. The writes need the uptime:manage scope. (Since v0.8.0.)

The same monitors are available to an AI agent over MCP (uptime_create, uptime_list, uptime_update, uptime_pause, uptime_resume, uptime_delete, uptime_status to troubleshoot, and uptime_outages for the incident log) and over the automation API. See Let an AI agent run DedNets and Script the API. Both need an API token with the uptime:manage scope (the reads also accept read). uptime_create and uptime_update take the same optional group, and uptime_list reports it. (Since v0.6.2.)

See also

Section titled “See also”