--- title: "Status page best practices | Logdash" description: "Where to host a status page, what to put on it, how to show uptime percentages honestly and how often to post during an incident, with numbers from GitHub and Vercel." url: https://logdash.io/status-page/best-practices --- # Status page best practices Host the status page apart from your app, drive it from real checks, list only what customers can tell apart, show uptime over a stated window rounded down, and post a timestamped update at least every hour during an incident. A status page has one job: answer "is it you or me" at the exact moment your app is broken. Every rule below follows from that moment. ## Host it apart from your app People open a status page when your app is down, and a page that shares its servers, deploys or DNS setup with your app goes down with it. Give it its own project and its own subdomain. The same goes for the checks behind it: a monitor running on the box it watches goes quiet exactly when you need it. ## What to put on a status page - One overall status at the top, in words: operational, degraded or outage. - A row per thing customers can tell apart: app, API, webhooks, sign-in. Not postgres-primary-2\. GitHub gets by with 11 rows. - 90 days of daily history. Long enough to show a pattern, short enough to stay current. - When the data was last updated. A visitor needs to know whether "operational" is 1 minute old or 1 hour old. - A way to follow along: an RSS or Atom feed, a subscribe button, or an email address, as Linear has. ## Status page uptime percentage State the window and say what counts as down. 90 days is the convention. At 99.9% over 90 days you may be down about 2 hours and 10 minutes; at 99.99%, about 13 minutes. Round down, never up: 99.996% shown as 100% claims a perfect quarter you did not have. Definitions differ too. incident.io counts degraded performance as up. Logdash counts a check as up only on a 2xx or 3xx answer, so the figure is successful checks over total checks. The Logdash status page API returns raw values such as 99.98835\. This prints each monitor rounded down to two decimals, and works as pasted against our own page: ```bash curl -s https://api.logdash.io/v1/status_pages/status.logdash.io | jq -r ' .monitors[] | .uptime["90d"] as $u | "\(.name): \(if $u == null then "no data" else "\(($u * 100 | floor) / 100)%" end)"' ``` Show the unflattering number. On 2 October 2026 Linear showed its EU application at 99.54% beside 100% for its API, and that is what makes the 100% believable. ## Status page incident communication - Post within minutes, before you know the cause. Say what is affected, not why. - Update at least every hour, even with nothing new. On 1 October 2026 GitHub posted 10 updates in 3 hours 9 minutes during an Actions incident. - Close with the exact window in UTC and who was hit. Vercel wrote "between 13:01 and 13:11 UTC" and named the Edge runtime. - Promise a root cause write-up and publish it. Logdash status pages show what the checks see. They have no incident editor and no subscriber list, so incident posts go wherever your customers already read you. The full status page reference is at /docs/status-pages. 1. **Monitor each component** Create a Logdash service per row you plan to show and point its HTTP monitor at a health URL. 2. **Publish on its own host** Publish the hosted page, or deploy the Next.js starter as its own project on status.yourdomain.com. 3. **Hear it first** Stop one service. On the next check the row turns red, and before anyone opens the page a Telegram alert reaches you with the status code. ### Logdash vs incident.io status pages | Feature | Logdash | incident.io | | ------------------------------ | ------------------------------------------------- | ------------------------------------------------ | | Incident posts and subscribers | Not built in | Built in, unlimited subscribers on the free plan | | Status from uptime checks | Built in, every 5 minutes free, 15 seconds on Pro | Follows incidents, fed by your monitoring tool | | Custom domain | Pro, or any plan with your own build | On the free plan | | Your own design | Public API, component and starter | Hosted page with branding | ### When incident.io is the better pick - Written incident updates and subscriber emails matter more to you than automatic status. - You already run incident response there and want the page to follow it. ### What are the most important status page best practices? Host it apart from your app, drive it from real checks, keep the component list short, and update during incidents on a schedule. A page that goes down with the app fails all four at once. ### What makes good status page incident communication? A first post within minutes saying what is affected, an update at least every hour, and a closing note with the UTC window and who was hit. Recent GitHub and Vercel incident posts are good models. ### What to put on a status page? Overall status, a row per component customers can tell apart, 90 days of daily history, the time of the last update, and a way to subscribe or get in touch. ### How should a status page uptime percentage be shown? Over a stated window, usually 90 days, with two decimals, rounded down. 99.9% over 90 days allows about 2 hours 10 minutes of downtime, 99.99% about 13 minutes. ## Keep reading [All status page guides](https://logdash.io/status-page): One page per question, from the status page API to a free page on your own domain. [Status page API](https://logdash.io/status-page/api): Every status page you publish in Logdash is also public JSON at api.logdash.io/v1/status\_pages/:id, with no API key and CORS open to any origin, so you can render it on your own site in your own design. [Open source status page](https://logdash.io/status-page/open-source): Logdash is AGPL-3.0 and its status page client, components and Next.js starter are MIT, but the checks and the data run on hosted Logdash, so if the whole stack must run on your own hardware, Uptime Kuma, Gatus or Upptime are the honest picks. [Free status page self hosted](https://logdash.io/status-page/self-hosted): Run the MIT-licensed Logdash Next.js starter on your own server or in Docker for a free self-hosted status page, while the checks behind it stay on the Logdash free plan, because the monitoring itself does not self-host in one command yet. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.