When something breaks, you do two jobs at once: fix it and tell people about it. Most teams fix in one tool and communicate in another — a status page vendor, a Slack channel, a tweet. OpsPing status pages put both jobs in one place. The incident you're working is the incident you publish.

One page, three visibility modes

Every status page lives at a URL you pick on status.ops-ping.com/<slug>. How public it is stays your call:

Curated incident publishing

Status updates aren't a firehose of your alert stream — they're written by a human, when you're ready. Pick an incident, publish it to the page, and post timeline updates as you learn more: investigating, identified, monitoring, resolved. The public sees a clean, chronological account of what happened and what you did about it. Nothing goes out until you hit publish.

Email subscriptions with double opt-in

Visitors can subscribe to the page by email. Confirmation is double opt-in: they sign up, they get a verification email, they confirm. That keeps your subscriber list clean and your sends compliant. When you publish an incident or a maintenance announcement, subscribers hear about it automatically.

90 days of uptime history

Each page carries uptime bars covering the last 90 days, one bar per day, so visitors can see at a glance how often — and how recently — things broke. No filling in gaps by hand; the history builds itself as the page runs.

Per-component status

Real services aren't one blob. Break your page into components — API, dashboard, background jobs, whatever matches your architecture — and track each one's status independently. An incident can degrade one component while the rest stay green, and your page shows exactly that.

Maintenance announcements

Planned work deserves its own channel. Schedule a maintenance window, and it shows on the page as a scheduled announcement ahead of time instead of reading like an outage after the fact. Subscribers get notified, so nobody files a ticket for the upgrade you told them about last week.

Why keep it in the pager?

If you've run Better Stack or Atlassian Statuspage, the feature set above will feel familiar — that's deliberate. The difference is where it lives. With a separate status tool, comms is a context switch: someone has to log into another vendor, recreate the incident, and keep two timelines in sync while the pager is still going off. With OpsPing, the incident and its public record are the same object in the same tool. The responder updating stakeholders is one click from the alert that started it — and when it's resolved, so is the page.

Status pages are included with OpsPing. Start a free trial and publish your first page in minutes, or see the full feature list.