Customer status pages

Weekly Update

When an incident is declared, you have the option to publish it on your internal status page, or onto a public status page. Sometimes, you want a middle ground. You may want to inform the customers that have been directly impacted, without creating noise by publishing onto your public status page to everyone, even those that weren't impacted.

Customer status pages are authenticated, dedicated pages for each of your customers, managed from one place. When you use customer status pages, you’ll write your incident update once, and have it shared only to the customers that are impacted by the incident. This can help scale your incident communication to hundreds of customers, while maintaining a more personalised experienced than a public status page can offer.

Easy access management

With customer status pages, you don't need to add every email address that should get access. Instead, you specify which email domains get access to a page, such as @incident.io. This makes it easy to manage access for an entire organisation, instead of having to go back into your configuration every time your customer needs another person added to their status page.

Powered by Catalog

Customer status pages are powered by Catalog, making it a breeze to configure your pages. Pages, components, and valid email domains are all configured through the Catalog, giving you the ability to manage your pages programmatically using our catalog-importer, or Terraform, alongside our Catalog UI.

If you’ve never used Catalog, don’t sweat. We can automatically set it up for you when you create your customer status pages.

To learn more and get started with customer status pages, head over to the help centre.

🚀 What else we’ve shipped

  • 🆕 Copy the incident ID and title via the CMD+K menu
  • 💅 We no longer display declined debrief attendees in the incident sidebar in the dashboard
  • 💅 We now prompt users to complete/convert actions to follow-ups before resolving an incident
  • 💅 Editing timestamps when creating retrospective incidents is now more intuitive
  • 💅 We let you filter incidents that are not a specific incident type in the dashboard
  • 🐛 The catalog importer will no longer allow deleting a catalog type being used by other resources
  • 🐛 When declaring a retrospective incident, you can no longer set your announcements channel as the incident channel
  • 🐛 Made it possible to update the phone number for incident subscriptions if your old phone number hasn’t been verified yet
  • 🐛 When handing over an incident, you can now hand it over to yourself

Operational excellence starts here