Incident Library
Applied filters SymptomNode disk fullFactorNo headroomOrganisationMailPaceClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. Symptoms

    At 13:36 BST on Friday August 11th 2023, minutes after MailPace reran its data clean-up job with more memory, notifications arrived that all database transactions were failing across multiple services. The managed Postgres database had gone offline, did not come back when restarted, and reported that it was out of space.

    Trigger

    The daily retention clean-up job, which had been failing with killed, was rerun with its memory raised from 1gb to 8gb, and its large destroy_all deletions filled the database disk.

    Root cause
    Component
    Contributing factor
    Detection

    Notifications that all database transactions were failing across multiple services arrived as soon as the outage began; the provider was automatically notified at 99% storage. MailPace's two status pages did not detect the outage.

    Remediation
    • Contacted the managed database provider's support
    • Notified users on Twitter and Mastodon
    • Prepared an offsite backup from six hours earlier on a new database instance as a fallback
    • The provider migrated the database to a larger instance
    • Removed the old data in production by hand, day by day, with an updated query
    Action items
    • Delete old data in batches of 50 records with in_batches in the clean-up job
    • Run the clean-up job four times a day instead of once
    • Stay on a much larger database instance with room to grow
    • Add cron monitoring to all cron jobs
    • Point the status pages at a /health endpoint that checks database access and returns a 500 error on failure
    • Investigate a hot-replica database for automated failover
    Lessons

    Several causes came together: a clean-up job that failed silently, a naive deletion that grew huge once data had piled up, a database plan without headroom for growth, and status pages that missed the outage, presumably because https://app.mailpace.com still answered 200 while the database was down. MailPace also advises that critical services such as email sending be set up with more than one provider.

Check your cluster for this

This case involves Database. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1