Postmortems

When something goes wrong, we write it up here. The format is always the same: what happened, why, what we did, what we learned. Even when nothing has gone wrong yet.

Incident archive

No incidents on record

We have not yet published a formal postmortem — either we've been clean, or we're still within the 48-hour publish window. Below you'll find a live feed of recent failed deploys from the last 30 days (auto-surfaced, not edited).

Recent failures (last 30 days)

Auto-surfaced from deployment_logs. These are deploy-level events, not necessarily customer-impacting incidents. If a deploy fails, we automatically retry.

Our policy

  1. Any customer-impacting incident (anything with a status page entry) gets a postmortem.
  2. Postmortems are published within 48 hours of resolution.
  3. We follow the format in the DR runbook: impact, timeline, root cause, what went well, what went poorly, action items.
  4. Names of affected customers are not published. Aggregate numbers are.
  5. Internal staff names are not published. Titles and roles are.

Subscribe

The changelog mentions every incident in its release notes. The status page has real-time incident tracking. Subscribe via the RSS changelog.

Why publish postmortems?

  • For customers. You deserve to know when something broke and what we did.
  • For ourselves. Writing the postmortem is when the real learning happens.
  • For the industry. Other hosting companies can learn from our mistakes.