Checks that say what they saw
Every check records its status code, its response time and the observer that ran it. A failure is a reading, not a guess.
Status unavailable
HTTP, keyword and port checks from a real vantage point, with incidents that record their own root cause and a public status page for your users.
Built and run by Rodmena Limited for our own fleet first. The numbers below are read from this installation, not written into the page.
How it works
An address is enough. Choose HTTP, a keyword the page must contain, or a TCP port, and set how often to look.
Checks run from a named vantage and record where they ran. A lease means a stalled prober is noticed rather than silently stopping.
Consecutive failures open an incident with its root cause — timeout, bad gateway, unauthorised — and it closes itself when the checks recover.
Email and webhook channels, each verified before it is trusted. Maintenance windows hold alerts during planned work instead of paging anyone.
Features
Every check records its status code, its response time and the observer that ran it. A failure is a reading, not a guess.
The error the check saw, recorded at the moment of failure, with the timeline of what happened next.
A page per audience, with the monitors you choose and ninety days of history.
Schedule the work and alerts for the monitors it covers are held until it ends.
Channels are verified before they are trusted, and can be tested on demand so you find out they work before you need them.
Everything the dashboard does, over HTTP, with keys you can scope and revoke. The reference is generated from the schema this installation serves.
API
Generated from the OpenAPI document this installation serves. A selection:
| Method | Path |
|---|---|
| GET | /api/monitors |
| POST | /api/monitors |
| GET | /api/monitors/{monitor_id}/checks |
| GET | /api/incidents |
| GET | /api/status-pages |
| POST | /api/maintenance |
| GET | /api/notifications |
| POST | /api/api-keys |
| GET | /api/health |
Status
Status unavailable
This page could not read the service's health. That is not the same as the service being healthy, so it is shown as unknown rather than as an all-clear.
Questions
You choose the interval per monitor, down to one minute. The badge at the top of this page shows the longest interval this installation is currently scheduling.
From a named vantage, and every result records which one. The number of vantages currently reporting is shown in the status section below.
No. Email and webhooks only. There is no SMS or voice sender behind this service, and a monitoring product that implies an alerting channel it does not have is worse than one that admits the gap.
Nothing yet. An incident opens after consecutive failures, so a single blip does not page anyone, and it closes itself when the checks recover.
Yes — every recorded check, with its response time and status, and every incident that monitor has had.
The monitors you put on it, their current state, ninety days of daily uptime, and the incidents you chose to make public. A day with no checks is shown as having no data, not as 100 %.
Yes, and the reference at /docs/api is generated from the OpenAPI document this installation serves, so it cannot drift from what the server actually accepts.
Rodmena Limited, a software company in London. We built it to watch our own services and run it on the same infrastructure we sell.
Start
No card, no sales call. Add a monitor and watch it check.