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

Cases2 cases

1 to 2 of 2

  1. Symptoms

    Between 23:30 UTC on 1 November and 1:10 UTC on 2 November 2025, both the Healthchecks.io website (healthchecks.io) and the ping endpoints (hc-ping.com) had intermittent connectivity problems: some requests took several seconds to finish and others timed out entirely. The load balancers were running out of connection slots and rejecting legitimate requests, and Healthchecks.io users received false monitoring alerts.

    Trigger

    A misconfigured client flooded the ping endpoint, raising requests for a single UUID from 10 to a sustained 300 requests per second.

    Root cause
    Component
    Contributing factor
    Detection

    Monitoring notifications woke the operator at 00:11 UTC.

    Remediation
    • Identified the offending client addresses, a single IPv4 address and a /64 IPv6 subnet
    • Changed the load balancer configuration to reject TCP requests from those addresses
    Action items
    • Rate-limit with HTTP 429 returned immediately (the "Deny" method) instead of the "tarpit" method
    • Add the missing timeout http-request 5s to the HAProxy configuration to guard against Slowloris attacks
    • Increase the maxconn parameter in the HAProxy configuration
    • Apply the load balancer rate-limiting rules to the hchk.io endpoints as well as hc-ping.com
    • Add a Netdata alert when active HAProxy frontend sessions pass thresholds well below maxconn
    • Change the HAProxy logging format to make the logs easier to use
    Lessons

    The tarpit rate-limiting method only slows clients that make requests one after another; a client sending many requests in parallel is not slowed, and the sockets held during the wait can exhaust the load balancer's connection slots. The operator called it one more lesson learned and switched rate-limited requests to the "Deny" method.

  2. Symptoms

    From 07:22 UTC on 22 February 2024, the bitbucket.org website and the Bitbucket Cloud APIs became slow, and Bitbucket Pipelines runs were badly delayed. Git requests over HTTPS and SSH kept working.

    Root cause
    Component
    Contributing factor
    Remediation
    • Added resources to Bitbucket Pipelines to clear the backlog of jobs, which was fully cleared by 17:30 UTC
    Action items
    • Reconfigure the vacuuming threshold for database tables with high write activity
    • Adjust alert thresholds to catch this behaviour earlier
    • Tune autoscaling and load shedding for the Pipelines services and increase build runner capacity
Check your cluster for this

These 2 cases involve PostgreSQL vacuum and 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