The engine behind the page.
StatusOwl's checks exist to answer one question on a schedule: is this service up right now? That answer is what your status page reads out, and what opens the incident when it stops being yes.
A check result is the only thing your page trusts.
There is no separate monitoring product to wire up and reconcile. The checks that decide whether a service reads operational are the same checks that open the incident when it does not.
The check comes due
Every monitor carries an interval. The scheduler queues the check when it is due, and the interval you can pick has a floor set by your plan.
A node runs it
An HTTP request, an ICMP echo, or a TCP connection — with your method, headers, timeout and expected status codes. Up or down comes back, along with how long it took.
The page reads it out
Each service on your status page is backed by a monitor. Its state, its 30-day uptime percentage, its latest response time and its 90 daily bars all come from those results.
Three failures open an incident
One blip posts nothing. Three consecutive failures opens an incident at the impact your page is configured for, and the first successful check posts a recovery update and resolves it.
- Type
- HTTP
- Interval
- 30 sec
- Last response
- 142 ms
- Consecutive failures
- 0
- Service state
The dot and the label next to the service name.
- 30-day uptime
A percentage to two decimal places, under the service.
- 90 daily bars
One bar per day, with date, uptime, average response time and check count on hover.
- Latest response time
The most recent measurement, if you leave response times switched on.
A failing check updates your page. It does not notify your team.
This is the most important sentence on this page, so it is not buried at the bottom of a feature list.
The six notification channels are built, tested and in production — but the only thing that currently triggers them is a Watch Owl server-metric alert rule. A failing HTTP, ping or TCP check opens an incident on your status page and notifies nobody. This is the single biggest gap in the product and it is what we are working on right now.
Concretely: when three consecutive HTTP, ping or TCP checks fail, StatusOwl opens the incident, puts the banner on your status page and keeps the timeline — and sends no email, no Slack message and no webhook. If being woken up is what you are shopping for, buy something that does that today and point it at the same endpoints. The one place the channels genuinely dispatch right now is a Watch Owl server-metric alert rule.
Where this stands on the roadmapFour things, and what each one is for.
Two of them decide what your status page says. Two of them tell you about problems that have not reached your users yet.
Uptime checks
HTTP and HTTPS with your method, headers, body, expected status codes and timeout — plus ICMP ping and TCP port checks. These are the checks a status page service is built on.
Read moreSSL and domains
Certificate issuer, subject, validity window and days remaining, with warning and critical thresholds. Plus WHOIS registration expiry and nameserver-change detection.
Read moreServer metrics
Watch Owl, a Go agent you install on your own Linux, Windows and macOS hosts. CPU, memory, per-mount disk, per-interface network and OS patch state, with threshold alert rules.
Read moreIntegrations
Email, Slack, Discord, Microsoft Teams, ntfy and signed webhooks. All six are built and testable — read the dispatch caveat above before you rely on them.
Read moreShared nodes, your own nodes, or nodes inside your network.
Most services only ever need the shared pool. The other two exist for teams who need checks isolated from other tenants, or who need to reach something the public internet cannot.
The shared pool
Every planThe default. Your checks run from StatusOwl's own checking nodes, alongside everyone else's. Nothing to install, available on every plan.
Dedicated nodes
1 on Starter · 3 on Growth · Unlimited on ScaleSingle-tenant checking nodes that run only your organisation's checks.
Nodes you run yourself
Counted as a dedicated nodeRun a checking node as a container inside your own network, so StatusOwl can check services that are not reachable from the public internet.
What each plan gets.
Every row here is a number the platform enforces. Nothing on this table is aspirational.
| Monitoring | Free | Starter | Growth | Scale |
|---|---|---|---|---|
Monitors HTTP/HTTPS, ping and TCP port checks. | 25 | 100 | 300 | 1,000 |
Check frequency | 3 min | 60 sec | 30 sec | 30 sec |
Automatic incidents Three consecutive failures opens an incident on the page and resolves it on recovery. | Included | Included | Included | Included |
SSL certificate expiry 25 certificates per organisation on every plan. | Included | Included | Included | Included |
Domain expiry (WHOIS) | Included | Included | Included | Included |
Server metrics agent Watch Owl — CPU, memory, disk and network from your own hosts. | 1 host | 1 host | 1 host | 1 host |
Dedicated checking nodes Single-tenant nodes, including nodes you run inside your own network. | Not included | 1 | 3 | Unlimited |
Check frequency is a floor, not a fixed rate
Attach a monitor, get a service
A status page service is a monitor you attached to a page. Nothing is duplicated and the two can never disagree about what happened.
The incident writes its own first update
Three consecutive failures opens it, seeds an automatically-detected update, and suppresses duplicates until it resolves.
History you did not have to keep
90 daily bars per service with the exact uptime, average response time and check count behind each one.
The page is the product. The checks are how it stays true.
Free forever on one page, with your own domain and automatic SSL — and 25 monitors before you pay anything.