Sorry Outage History

We resolved a bug where some subscribers set to receive notifications for "All components" were incorrectly shown as subscribed to "Only certain components" when editing them in the Management UI. This was a display issue only - no notifications were affected, and all subscribers continued to receive the correct alerts throughout.

We just released a fix to the email which is sent to subscribers when they want to manage their subscription preferences. Before the fix, the email heading didn't correctly include the status page name, instead showing a placeholder. We also took this opportunity to rework the email copy to better align with the language of the subscriber journey. The email now uses the phrase "Manage Subscription" rather than "Sign-in" to better match the experience on the status page itself.

Starting on May 12th, following the [release of our notice archiving feature](https://status.sorryapp.com/notices/ka9bfnq7spwssppy-automatic-notice-archiving) we saw a slow-down in the performance of uptime calculations - this was introduced by a change in the calculation that conditionally included archived notices based on who was viewing the status page. This was primarily impacting requests on the Status API, and likely wasn't noticeable to everyday users. We have now fixed the issue, so performance has returned to it's usual speed.

Old notices on your status page are now automatically archived after a configurable time period. Once archived, notices become visible only to your team — keeping your status page clean and focused on what matters most. **What's new:** - Notices older than your chosen threshold are automatically archived - Archived notices are only visible to your team. Anyone else viewing your status page won't see them. - Your team retains full access on the status page when logged in, and in the management dashboard - A 3-year default has been applied to all existing pages [Learn more in our help center](https://help.sorryapp.com/article/185-notice-archiving)

We no longer inject Google Analytics or Google Tag Manager into Error, Maintenance or 404 pages. This will help prevent white-noise from these bad requests from polluting your real visitor data.

For the few customers using our experimental metrics rules to control who can see uptime on the status page, we have added a new preconfigured "Team" audience that lets you easily limit visibility to people on your team, without needing to build a custom rule that matches by email addresses or domains. This is also part of the foundation work we're building for our new notice archiving feature.

We have just released some behind-the-scenes changes to the status page theme, cleaning up the code and making some minor performance improvements before adding new features in the coming weeks.

We've just released some improvements to the way that a notice's position in the timeline is calculated. (future, present, past) This has no outward impact on customers, but does gain us a slight performance improvement. The main motivation however is laying the groundwork for an upcoming feature that allows you to archive old notices. Watch this space.

We've added a new notice type to your status page. General Notices let you share updates that aren't incidents or maintenance — things like release notes, security advisories, domain changes, or end-of-life announcements. They're simpler than other notice types: no status to track, no timeline to manage. Write your message, optionally tag it to categorise it (e.g. "New Feature", "Security", "Bugfix"), and post. You can notify subscribers when posting a General Notice across all your configured channels. Create them from the dashboard using the dropdown on the "New Notice" button, or through the API.

Following on from [yesterday's performance improvements](https://status.sorryapp.com/notices/vvlrvcs219xzblq6-performance-improvements) we have today made a few further tweaks to the way that uptime metrics are calculated for display on the status page. These improvements apply across the board - your status page, notices, and the status API all benefit from the faster loading times, particularly for customers with larger numbers of components.

We identified a deployment released at 14:15 UTC as the cause of the management UI loading slowly or failing to load. The deployment was rolled back at 15:01 UTC, and the UI has since recovered. We’re currently monitoring the service to ensure it remains stable. The cause of the deployment failure will be analysed as part of our internal post-incident review.

We've made performance improvements to how component metrics are loaded on your status pages. Pages with uptime metrics enabled will now load noticeably faster, particularly for status pages with larger component trees. These improvements apply across the board - your status page, notices, and the status API all benefit from the faster loading times. No action is needed on your part, the improvements are already live.

We've redesigned how you create notices from the dashboard to make it faster to post the right type of update. The "New Notice" button in the navigation bar now includes a dropdown menu that lets you jump straight into creating a specific notice type — **Incident**, **Maintenance**, **Historic**, or **General** — with the form pre-filled to the right settings. Previously, shortcuts for creating notices were tucked inside the timeline sections on the notices page. This new approach puts them all in one consistent place, always accessible regardless of which page you're on. The primary button still works exactly as before — click it to open the notice form and choose your type from there.

If you're using general notices to share updates with your users, those notices are now included in your Status API responses. General notices will appear alongside your existing planned and unplanned notices when listing notices via `/api/v1/notices`, and can be retrieved individually via `/api/v1/notices/:id`. You can also filter for them specifically using `?filter[type_eq]=general`. Since general notices don't have a lifecycle like incidents or maintenances, their API payload is a little leaner — fields like `state`, `began_at`, and `ended_at` are omitted. Full details are available on the API documentation tab of your status page.

We have significantly improved the performance of activity reports for accounts with large numbers of subscribers and components. Reports that previously took several seconds to load should now render much more quickly. No changes to how reports work — just faster results.

We've been alerted by our monitoring systems that the **Sorry™ Help Centre** is currently unavailable. If you need to get in touch with us, you can still contact our team using the in-app beacon or by emailing **[email protected]**. We're monitoring the situation closely and will share updates as soon as we receive more information from our service provider, Help Scout. Thank you for your patience.

Our monitoring, along with confirmation from Help Scout, shows that the issue has recovered and the Sorry™ Help Centre is now available again. We'll continue to monitor the service and, if everything remains stable, we'll resolve this incident shortly.

We have resolved an issue where adding a new team member could fail with a timeout error on accounts with a large number of status pages. Team members are now added instantly, with their page access being set up seamlessly in the background. No action is needed on your part.

The activity report for page collections was undercounting subscribers. Subscribers who had selected specific child components — but not every component under a page — weren't being included. These counts now accurately reflect all subscribers, regardless of how granular their component selections are.

We just released some under-the-hood changes to how we generate and store data for the new Activity Summary, in preparation for a bunch of new features landing in the near future.

SSL certificates for newly added custom domains sometimes failed and were not retried, leaving new customers with a certificate error during setup. We have made this provisioning more resilient, so it should no longer impact people as often.