Documentation
Run your own status page
Better Status Page is a self-hosted status page and uptime monitor. These guides cover installing it, keeping it running, and connecting it to the tools your team already uses.
Get started
Monitoring
MonitorsA monitor checks one thing on a schedule — a URL, a host, a DNS record, a database — or waits for your own service to call in. This guide covers every monitor type, the fields in the monitor form, authentication, certificate warnings, dependencies and the built-in test runner.Notification channelsNotification channels tell your team when a monitor goes down, degrades, recovers or has a TLS certificate about to expire. A channel is one destination — an email address, an HTTP endpoint, a Slack, Discord or Microsoft Teams webhook, a Telegram chat, an ntfy topic, a Pushover recipient — and you decide per monitor which channels it alerts.Alert hygieneThe most common reason people stop trusting a monitoring tool is that it alerts too much. One flapping endpoint, one bad deploy, one night shift — and the alert channel gets muted forever.ActionsAn action sends an HTTP request when a monitor stays down or comes back up. Where a notification channel tells people something happened, an action changes something outside BetterStatusPage: it starts a failover job, wakes a standby server, or switches a feature flag.Uptime reportsThe status page shows the last 30 days of each monitor as a bar. Monitoring → Reports in the admin console goes further back and further into the numbers: pick any date range, see the uptime of every monitor, and download it as CSV for an SLA review or a customer.
Status page
Incidents and maintenanceMonitors report what the checks see. Incidents and maintenance windows are what you tell visitors: an incident explains a problem and how it is going, a maintenance window announces planned work and keeps your notification channels quiet while it runs.Customizing the pageThe public status page is built from three admin pages: Page Builder decides what is on the page and where, Branding decides how it looks, and Localization decides which languages visitors can read it in. This guide covers all three, plus dark mode and live updates.SubscriptionsNotification channels (Notifications in the admin console) alert your team when a monitor changes status. Subscriptions are the other direction: they let the people who read your status page follow what you publish — by email, by webhook, in a Slack channel, through an RSS/Atom feed, or by polling a JSON API.Private status pageBy default the status page is public: anyone with the URL can see it. An administrator can make it private. A private page only shows its content to signed-in users. Everyone else gets a sign-in screen in the page's own branding, where they sign in with a password or through single sign-on.Static fallbackWhen the server that runs BetterStatusPage is down, the status page is down with it, which is when visitors want it most. The static fallback keeps a saved copy of the public page on static hosting that does not depend on your server, so that visitors still see the last known state, with a banner saying when it was taken (you can turn the banner off).
Integrations
SlackReceive monitor alerts directly in a Slack channel as rich Block Kit messages — color-coded by severity, with all relevant details included automatically. No bot token or Slack app required. Just an incoming webhook URL.DiscordReceive monitor alerts directly in a Discord channel as rich embeds — color-coded by severity, with all relevant details included automatically. No bot token, no OAuth, no bot invitation. Just a webhook URL.Microsoft TeamsReceive monitor alerts directly in a Microsoft Teams channel as formatted MessageCards — color-coded by severity, with all relevant details included automatically. No app installation or bot token required.TelegramReceive monitor alerts in a Telegram chat, group or channel as formatted messages with a severity emoji and all relevant details included automatically. You need a bot token and the ID of the chat that should receive the alerts.
Security
Users and rolesEvery person who signs in to BetterStatusPage has their own account with one of four roles: admin, operator, branding or viewer. This guide covers what each role can do, how administrators manage users, passwords and two-factor authentication, and the two admin pages that watch the instance itself: the Audit Log and System Health.Single sign-on (OpenID Connect)BetterStatusPage can sign administrators in through any OpenID Connect (OIDC) identity provider: Microsoft Entra ID, Keycloak, Okta, Google Workspace, Authentik, Auth0 and others. Sign-in uses the Authorization Code flow with PKCE, state and nonce, and ends in the same server-side session (HttpOnly cookie + CSRF token) as a password sign-in.Secrets vaultThe vault keeps the passwords, tokens and connection strings your monitors and email delivery need, encrypted in the BetterStatusPage database. A monitor or the SMTP settings then point at a secret instead of holding the credential themselves.API and tokensThe admin panel is a client of the same REST API you can call from scripts, CI/CD pipelines and infrastructure tooling. Everything under /api/v1/admin accepts an API token in place of a signed-in session.
Operate
Configuration as codeMonitors and notification channels can be written as YAML documents, and created or updated from them. A document does not depend on the numeric ids of an installation, so it reads the same anywhere, diffs well in version control, and can be reviewed like any other configuration file. A pipeline that applies the documents on every merge keeps the installation in step with the repository.Backup and restoreBetterStatusPage stores runtime state in SQLite plus uploaded assets. Backups are built into the application so operators do not need to copy a live WAL-mode SQLite database manually.