Introducing status page sub-pages

Weekly Update

We launched Status Pages earlier this year to help organisations provide their customers with clear and timely communication during incidents, with as little friction as possible.

However, for some organisations, clear communication doesn’t always mean pushing out the same updates to the same audience.

Especially if you’re a B2B company, or operate in multiple geographies, many of you have said you’d really love to be able to provide distinct status pages for every audience but without the additional overhead of managing them all independently.

Today, we’re delighted to announce we’ve shipped Status Page sub-pages.

Sub-pages unlock the ability to:

  • Define relationships between different status pages
  • Seamlessly provide updates to multiple status pages at once
  • Tailor those updates based on the relationships between the pages

Should I be using sub-pages?

If you find yourself needing to communicate with distinct groups or audiences, then sub-pages could work well for you. A few examples of where customers are using this:

  • You have a product that operates across multiple regions or geographies, and you would like a separate status page for each of them
  • You provide multiple very different products or services and the users of those products are also fairly independent from each other

Check out our help center articles for more information about sub-pages, and guides to help you get up and running with them.

We now show more incident details when you share a link to an incident in Slack.

Public incidents show the title, summary, severity, status, and a link to the channel. Private incidents show just the incident number and a link to the private channel, for those already in it.

We’ve deliberately chosen not to enable this for guest users, or in Slack Connect channels to avoid unintentionally sharing information.

🚀 What else we’ve shipped

🆕 You can now include the post-mortem as a button on announcement posts

🆕 You can now set the call_url for an incident via the public API

👷 We’ll now render timelines faster if you have large debrief meetings

💅 When we link to a Slack channel in app, it’s always a deep link to avoid popping you out into a web browser

💅 Internal statuspage components with long descriptions now render more nicely in a tooltip

💅 Tidied up the styling we use for catalog icons

💅 We’ve improved styling on the ‘key information’ section for internal status pages

💅 Status page subscription emails will now explicitly call out if an incident is new or not

💅 We’ve made component status icons consistent across status page incidents

💅 We've made the copy less confusing when you deploy a workflow

💅 We now correctly refer to "resolving" the incident rather than "closing" on the nudge when there's been no activity

🐛 When you stop editing a catalog type, we’ll always return you to that type (and not the catalog homepage)

🐛 When you create an incident from a message, we will unfurl the source message in the incident channel

🐛 When editing incident roles in the dashboard, we’ll now always populate the existing assignments

🐛 Fixed a bug where we were showing duplicate participants on the incident homepage

🐛 We now render activity in the workflows tab with the first step at the top, not the bottom

🐛 You can now change where a query expression starts when you’re using ‘All of <Catalog Type>’

🐛 We now stop you from deleting a custom field or other resource if your policy expression uses it

🐛 We’ve fixed a bug around certain links getting duplicated in debrief documents

🐛 We’ve improved error messages when an incident fails to sync to Jira

Operational excellence starts here