The agent that watches the host from the inside.
Uptime checks tell your status page whether a service answered. Watch Owl tells you what is happening on the machine behind it — CPU, memory, disk, network and patch state — before that becomes the reason it stops answering.
One Go binary, running as a background service.
No runtime to install, no language SDK, no agent framework. It collects on a short interval and ships to StatusOwl over HTTPS, and each host keeps a stable identity in your dashboard.
Linux
The common case — a service host, a database box, a build runner.
Windows
Same agent, same metrics, same alert rules.
macOS
For build machines and anything else on your own hardware.
Host metrics live in your dashboard, not on your public status page. What your visitors see still comes from the uptime checks attached to that page.
- CPU
- 37.4%
- Memory
- 68.1%
- Disk · /
- 41.0%
- Disk · /var/lib
- 88.6%
- eth0 in
- 18.2 MB/s
- eth0 out
- 6.4 MB/s
- Pending updates
- 14
- Reboot required
- No
Six things, measured properly.
Per mount and per interface, not host-wide averages that hide the mount and the interface that are actually in trouble.
CPU
Utilisation on the host, sampled continuously and stored as a time series rather than a last-seen number.
Memory
How much is in use and how much is genuinely available — the figure that tells you whether the next deploy fits.
Disk, per mount
Every mounted filesystem separately. A root volume at 40% tells you nothing when /var is at 98%.
Network, per interface
Inbound and outbound throughput broken out by interface, so a busy private link is not hidden inside a host total.
Host metadata
What the machine actually is — the identifying detail you need when the hostname alone is not enough to place it.
OS patch and reboot state
Pending updates, security updates, and whether the operating system is flagging that a reboot is required. The neglected-server failure mode, made visible.
A threshold, a hold, a cooldown and a scope.
Rules are evaluated on our side against the metrics your agents push, so there is nothing to configure per host. Write the rule once and point it at the hosts it applies to.
Condition
A metric, an operator and a value — disk_percent > 90, or reboot_required = true.
Hold duration
How long the condition must hold before the rule fires. Zero fires on the first sample; five minutes ignores the spikes that resolve themselves.
Cooldown
How long the rule stays quiet for that host after firing. The event still resolves on its own — the cooldown only suppresses a new fire.
Scope
All hosts, hosts carrying a tag, or one specific host. Tag a machine on enrolment and it joins every rule scoped to that tag.
| cpu_percent | Host CPU utilisation |
| memory_percent | Memory in use |
| disk_percent | Fill level, with a mount filter |
| network_rx_bytes_per_sec | Inbound throughput, with an interface filter |
| network_tx_bytes_per_sec | Outbound throughput, with an interface filter |
| reboot_required | The OS is asking to be restarted |
| pending_updates | Count of available package updates |
| security_updates | Count of security-only updates |
| host_offline_seconds | Seconds since the host last reported in |
- Metric
- disk_percent
- Mount filter
- /var/lib
- Condition
- > 90
- Hold for
- 600 sec
- Cooldown
- 3600 sec
- Scope
- env=prod, role=db
This is the one path where the channels genuinely fire.
StatusOwl has six notification channels, all built, all in production, each with a live test-send button. A Watch Owl alert rule is the only thing wired to trigger them today — so this is the honest version of “we can alert you”.
Delivered through Resend.
Slack
Into the channel you pick.
Discord
Same, for the teams that live there.
Microsoft Teams
Same, for the teams that do not.
ntfy
Push to a topic you own.
Webhook
Optional HMAC-SHA256 signing, three attempts with backoff, through an SSRF-guarded client.
A failing HTTP, ping or TCP check dispatches nothing. It opens an incident on your status page and notifies nobody. Everywhere outside Watch Owl alert rules, these six channels are configured and idle. Routing check results to them is the single biggest gap in the product and the thing being built right now.
Where that standsEvery integration selected on a rule receives the event at the same time. There are no escalation policies, no on-call schedules, no SMS and no phone calls. If you need any of that, send the webhook to the tool that already does it.
All six integrationsEvery fire, with the number that caused it.
An alert you cannot audit afterwards is a rumour. Each event records when it fired, the metric value at the moment it fired, when it resolved, and whether each integration actually accepted the message.
| Rule | Host | Fired at | Value | Resolved at | Dispatch |
|---|---|---|---|---|---|
prod-db disk near full | db-primary | 2026-07-14 02:41 | 94.2% | 2026-07-14 03:10 | Slack sent · Email sent |
Reboot pending | web-03 | 2026-07-16 06:00 | true | — | Webhook sent |
Host offline | runner-02 | 2026-07-18 21:07 | 312 sec | 2026-07-18 21:19 | Email sent · ntfy failed |
One host per organisation, on every plan.
Including Scale. That is the cap the platform enforces today, and it is on this page rather than in a footnote because it is the thing most likely to rule Watch Owl out for you.
| Plan | Server metrics agent |
|---|---|
Free | 1 host |
Starter | 1 host |
Growth | 1 host |
Scale | 1 host |
Watch Owl — CPU, memory, disk and network from your own hosts. Alert rules, scopes and event history are included on every plan — the cap is on how many hosts can report at once.
Watch Owl alert rules are the only production path from a threshold to a notification. A failing website check still opens an incident on your status page and sends nothing. If your reason for adding StatusOwl is to be told when a site goes down, that is not shipped yet — read the roadmap before you decide.
Install the agent, write one rule, see it fire.
Free forever on one page, with your own domain and automatic SSL. Watch Owl and its alert rules are included from the Free plan up.