Skip to content
IncidentBot

Product

Solutions

Resources

Log in

Status page app and status page software connected to your incidents

Customers forgive an outage faster than they forgive silence. IncidentBot includes a hosted status page that knows about your incidents: when a responder posts an update, a status page draft is ready with the affected components and the current state, and publishing it takes one click. Subscribers are notified, the page stays consistent with the incident record, and nobody has to log in to a separate tool in the middle of a SEV1.

Run a sample incident

Checkout status

Degraded performance
TimeStatusUpdate
14:12:30InvestigatingWe are investigating slower checkout responses. Next update in 30 minutes.
14:29:05IdentifiedA recent release is the cause. A rollback is under way.
14:41:40ResolvedCheckout response times are back to normal.

Status updates drafted from the incident

When someone runs /incident update in the incident channel or changes the incident status, IncidentBot prepares a draft for the status page. The draft names the affected components, the current state (investigating, identified, monitoring, resolved) and a plain-language summary you edit before it goes out.

Run a sample incident
  • Components map to your services, so an incident on checkout-api marks the Checkout component.
  • Nothing is published without a person pressing publish. Internal details stay in the channel.
  • Each published update is written to the incident timeline, so the incident postmortem shows exactly what customers were told and when.
  • Scheduled maintenance is announced on the same page and matches the maintenance windows that silence alerts.

A system status page for customers, and a private one for your company

A public page tells customers what is working. A private page, visible only to signed-in people from your organization, tells support, sales and internal teams what engineering already knows. Both are updated from the same incident.

  • Public page: your components, current status, active incidents, maintenance, and incident history.
  • Private page: internal components and dependencies, for employees and service desk agents.
  • Audience-specific pages on Business: separate pages for a region, a product line or a large customer, each with its own components.
  • Custom domain such as status.yourcompany.com with HTTPS handled for you.
  • Your logo, colors and component groups, so the page reads as part of your product.

Subscriber notifications customers can control

Visitors subscribe by email to the whole page or to the components they depend on. When you publish an update, subscribers get it right away, and they unsubscribe from a link in every message.

  • Component-level subscriptions, so a customer who only uses the API is not notified about the dashboard.
  • Maintenance notices before the window starts, and a closing note when it ends.
  • Incident history on the page, so a customer checking after the fact sees the full sequence of updates.

Statuspage software built into incident response

In many stacks the status page is a separate product with its own login, its own seats and its own bill, and the person running the incident has to remember to go there. In IncidentBot the status page is part of the same record as the page, the Slack channel and the postmortem, which is why updates actually get posted during the first half hour.

If you are on Atlassian Statuspage today and also pay for a separate pager, our Statuspage alternative page compares the two setups plan by plan, with the monthly cost for a 10 responder team, and our Atlassian Statuspage pricing breakdown lists every public and private plan with its limits.

  • One place to publish from: the incident channel or the incident view.
  • One set of services and components, shared with alerting and incident tracking.
  • Status pages are included in the plan price rather than sold as an add-on.

Hosted status page, or a self hosted status page?

Some teams consider running a self hosted status page on their own servers. The catch is that a status page has to stay up exactly when your infrastructure does not. IncidentBot hosts status pages on infrastructure separate from yours, so your page answers even when your own cloud region, DNS provider or load balancer is the thing that failed.

Which plan includes which status page

Starter includes one public status page. Team includes three status pages with subscriber notifications and a custom domain. Business includes unlimited status pages, including audience-specific pages, plus SLA and uptime reporting per service. Stakeholder viewers are included on every plan and are not billed. Full detail is on the pricing page.

See pricing

Questions

Can the status page update on its own when an alert fires?

Updates are drafted, not published on their own. A monitoring blip should not tell your customers you are down, so a responder confirms and publishes. On Business, workflow automation can prefill the draft for specific services and severities.

Can we move from our current status page?

Yes. You recreate components and groups once, point your status subdomain to IncidentBot and invite existing subscribers to confirm. Your past incident history can be added as history entries.

Does the status page work if Slack is down?

Yes. You can publish from the incident view in the web app, and the status page itself does not depend on Slack in any way.

Can we show uptime on the page?

Yes. Component uptime bars come from your incident history. Per-service SLA and uptime reporting for internal review is part of Business.

Keep customers informed without leaving the incident

Connect your services, publish a status page on your own domain and let every incident update draft itself for review. Try the full flow on a sample scenario in the incident response platform demo first.

Run a sample incident