Sorry had 20 outages in the last 2 years totaling 196h 3m of downtime — averaging 0.8 incidents per month.
There were 20 Sorry outages since January 30, 2026 totaling 196h 3m of downtime. Each is summarised below — incident details, duration, and resolution information.
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.
We’re currently experiencing issues with our X/Twitter integration, which means notices are not being published there at this time. All other notification and message delivery channels are operating normally while we investigate the issue.
The issue affecting our X/Twitter integration has now been resolved and notices are once again being published normally. Thank you for your patience while we worked on this. All notification and message delivery channels are now operating as expected.
We've made a couple of small fixes to the Activity Summary shown at the top of your notice timeline: - Fixed an alignment issue where tile values appeared centered when there was no detailed breakdown to display. Values now consistently align to the left across all tiles. - Renamed the "Notices" tile to "Notices Created" to make it clear the count reflects notices created within the last 30 days.
We have patched an issue that was preventing some customers from completing the configuration flow when installing our Intercom Messenger App. This primarily affected accounts with multiple status pages. The app should now configure successfully for all accounts.
Your dashboard now features an Activity Summary — a quick snapshot of what has been happening on your status page over the last 30 days. At a glance, you will see: - **Notices published** — broken down by incidents and maintenance - **Notifications sent** — with a breakdown of your most-used channels - **Subscriber count** — including how many new subscribers joined recently The summary appears automatically on your Notice Timeline when there is recent activity, so you always have a pulse on how your status page is performing — without leaving your management console. This is just the beginning — we have plans to bring you even more insights into your status page activity. Stay tuned!
You can now permanently dismiss the onboarding setup tasks from your status page dashboard. If you have completed your setup, or simply prefer a cleaner workspace, click Dismiss to hide them for good. We have also improved how the hide/show toggle works. Previously, collapsing the setup tasks only lasted for your current browser session. Now your preference is saved to your account, so the panel stays how you left it even if you switch browsers or clear your cache.
We have added a 24-hour cooling-off period when deleting established status pages. Previously, deleting a status page was instant and irreversible. Now, when you delete a page that has built up subscribers and incident history, the deletion will be scheduled rather than happening immediately. Smaller or newly created pages will continue to be deleted straight away, so this will not slow you down during initial setup. This applies to standalone pages, collections, and individual pages within a collection.
We deployed some small changes to how we enable custom HSTS (Strict-Transport-Security) headers for particular status pages. This is a behind-the-scenes improvement and does not impact customers.
We have resolved an issue where magic link authentication responses were being cached by our CDN, which could cause links to fail after being accessed by email security bots. All magic links now work reliably on every click.
Customers were occasionally seeing errors when trying to delete incidents for which someone had previously removed the uptime impact. You may also have seen this error when deleting a page which contained an affected notice. This was a behind-the-scenes database constraint issue that has now been fixed.
We have a known bug that causes users to receive errors when trying to delete a notice that has an uptime impact they previously removed. We have just released the initial groundwork required to fix this bug, with the full fix to follow. This release changes how we track when and by whom an uptime impact was removed from a notice under the hood, without any visible changes to customers.
We have fixed an issue where importing from Atlassian Statuspage could fail with an unhelpful error message when there was a problem with your credentials. Now when you import from Atlassian Statuspage, you will see clear, actionable error messages if: - Your API Key does not have permission to access the specified Page ID - We are unable to connect to Atlassian Statuspage due to a temporary issue This makes it much easier to troubleshoot and resolve any issues when setting up imports from Atlassian Statuspage.
If you are using page collections and importing incident templates from Atlassian StatusPage, we have got good news! Previously, imported templates would always appear as shared templates across your entire collection. Now, when you import into a specific page within your collection, those templates are automatically organized under that page—exactly where you would expect them to be. This means less manual reorganization after imports, and your templates stay neatly grouped with the pages they belong to. Happy importing! 🎉
We have fixed a bug where subscriber counts displayed on the pages index were incorrect for pages within collections. The counts were underreporting the true number of subscribers. Subscriber counts now accurately reflect all subscribers for each page in your collections, including those subscribed to specific components and those subscribed to all components.
Everything continues to look happy and stable for the past hour, with no further performance issues flagged since that slight wobble between 00:55 and 01:05 UTC. All the data we're seeing suggests that the issue was a general network slowdown, somewhere outside of our infrastructure, between our edge servers and our main platform. We're happy to consider this incident as resolved.