Status page
A status page is a public page that says whether your product works right now and how it did over the last 90 days, and Logdash builds one from its own uptime checks, so it turns red on the next failed check without anyone updating it by hand.
Most status pages are updated by a person. During an outage that person is busy fixing the outage, so the page keeps saying all systems operational well into the outage, which is exactly when customers open it. A status page earns its keep only if it turns red without anyone touching it.
A Logdash status page reads from the same HTTP checks that alert you. Each monitor is checked every 5 minutes on the free plan, every minute on Builder and every 15 seconds on Pro, and the page shows what those checks saw.
What the page shows
- One overall status: operational, degraded or outage.
- A row per monitor with its uptime over 24 hours, 7, 30 and 90 days.
- 90 daily bars per monitor, each with its checks and average latency.
- A response time chart over the last 100 checks, and when the data was last updated.
- No incident posts, maintenance windows or subscriber emails. The page reports checks, not prose.
How the status is decided
- A check is up when it gets a 2xx or 3xx answer. Anything else, or no answer within 10 seconds, is down.
- A monitor is down when its latest check failed, degraded when any of its last 10 checks failed, and up otherwise.
- The page is in outage when every monitor is down, degraded when any monitor is not up, and operational when all are up.
- Uptime is successful checks over total checks in the window.
- The page is composed at most once a minute, so what a visitor sees can be up to about three minutes old. The Telegram alert does not wait for it.
Your domain or your own design
The hosted page lives at logdash.io/d/<id> on every plan. On Pro, one CNAME to statuspage.logdash.io puts it on a subdomain such as status.example.com, with HTTPS handled for you. The other route works on any plan: every published page is also public JSON with no API key, so you can render it in your own app with the MIT React or Svelte component, or deploy the Next.js starter on any domain you own.
curl -s https://api.logdash.io/v1/status_pages/status.logdash.io \
| jq '{status, updatedAt, monitors: [.monitors[] | {name, status}]}'Wherever it ends up, host it apart from your app. A status page that shares servers, deploys or DNS with the product goes down with it, at the one moment people come looking.
Logdash vs hand-updated status page tools
| Feature | Logdash | Statuspage, incident.io |
|---|---|---|
| What turns the page red | The next failed check | A person, or a monitoring tool you connect |
| Incident posts and maintenance | None | Written by you, free plans included |
| Subscribers on the free plan | None | 100 on Statuspage, unlimited on incident.io |
| Your own domain | Pro at $15, or your own build on any plan | Statuspage from $29, incident.io free |
When a dedicated status page tool is the better pick
- You write incident updates by hand and want customers to subscribe to them by email or SMS. Logdash has no incident editor and no subscriber list.
- You announce scheduled maintenance on the page. Logdash shows checks only.
- Your monitoring already lives elsewhere and only the communication layer is missing.
Set it up
- Add your monitors Create one Logdash service per thing customers can tell apart, such as the app and the API, and point each HTTP monitor at a health URL.
- Publish the page Pick the monitors, name the page and publish it. The free plan includes one status page and five monitors.
- Break one on purpose Connect Telegram and make one health URL return a 503. The row turns red within a few minutes, and the Telegram alert reaches you first, with the monitor name and status code.