Unable to access Capsule

Update timeline

1. investigating Mar 27, 2026, 01:26 AM UTC

   We are aware of an issue preventing customers from accessing Capsule at the moment. We are working hard on getting this fixed and we'll be sure to post an update once we're back online.

2. monitoring Mar 27, 2026, 01:43 AM UTC

   We have managed to restore service. The root cause is under investigation and an update will be provided as soon as possible. If you are still having issues accessing your Capsule account please contact [email protected].

3. monitoring Mar 27, 2026, 08:56 AM UTC

   A repeat of the service failure has occurred. We are still investigating the root cause for this incident but Capsule is back online. Updates will be posted as we learn more.

4. monitoring Mar 27, 2026, 09:15 AM UTC

   We believe we have found the root cause for this issue and a fix is currently being deployed.

5. monitoring Mar 27, 2026, 10:15 AM UTC

   The fix has been deployed and we are seeing normal response times in app. A full incident report will be published in due course.

6. resolved Mar 27, 2026, 04:48 PM UTC

   This incident has been resolved.

7. postmortem Mar 27, 2026, 04:48 PM UTC

   # Incident Summary On Friday, March 27, 2026, Capsule experienced several periods of slow performance and some temporary outages. These were caused by two separate and unrelated issues: * A recent software update that unintentionally caused parts of the system to become stuck. * An uncommon data pattern which led to degraded performance under specific conditions. Both issues have now been resolved. The first was fixed by rolling back the recent update, and the second by mitigating the data pattern that caused the issue. At no point was any customer data impacted. # Timeline of Events _\(All times are UTC\)_ * **00:01** – A small number of users began experiencing errors when using the web app and API. * **01:00** – Errors increased significantly, triggering an alert to our on-call engineers. Investigation began. * **01:35** – The team observed locking behavior and replacement servers deployed to mitigate. * **02:09** – Service appeared stable, with further investigation ongoing. * **08:37** – Errors reappeared for a small number of users. * **08:46** – Errors increased again, and engineers were alerted. Initially thought to be a repeat of the earlier issue. * **08:54** – Initial fixes were applied, partially restoring service. * **09:12** – The earlier issue was fully identified and fixed by reverting the problematic update. * **09:34** – While monitoring the fix, a second issue was observed. * **09:54** – The cause of the second issue was identified, linked to an uncommon data pattern. Fixes were applied and service was restored. * **12:30** – Reprocessing this data caused another spike in errors. * **13:00** – Mitigation put in place for the data pattern, and full service was restored. # Next Steps We are carrying out a full internal review of both issues. Based on this, we will introduce additional safeguards to prevent similar problems from happening again.