Incident Library
Applied filters ComponentDatabaseFactorMonitoring blind spotOrganisationHerokuClear 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

    From 22:31 UTC on 27 July 2024, 33 Heroku Postgres clusters in the EU (Dublin) region could not serve requests and ran into memory problems, and some Essential-tier customers could not connect to their databases. Customers trying to reach an affected database received out of memory errors.

    Trigger

    A third-party vendor deployed a change to a monitoring agent that runs on Heroku's Postgres database clusters.

    Root cause
    Component
    Contributing factor
    Detection

    Heroku Support paged the technology team at 07:50 UTC on 28 July based on customer support tickets. The second occurrence also reached the technology team as an escalation from Heroku Support.

    Remediation
    • Allocated more resources and restarted the Postgres clusters, which fixed the first outage temporarily
    • Provisioned the previous version of the third-party monitoring software, which did not leak memory
    • The vendor applied an interim mitigation
    Action items
    • Add enhanced metrics collection for the third-party monitoring software
    • Evaluate the vendor's fixed release of the monitoring software and roll it out if acceptable
Check your cluster for this

This case involves Database and Telemetry agent. 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