Incident

Across all three regions and the full incident window, DNS resolution (17–19 ms), TCP connect (29–34 ms) and TLS handshake (42–47 ms) remained within one standard deviation of their 7-day baselines, while TTFB rose by a factor of 26 before failing. The connection is established normally and the TLS session completes; the origin simply does not produce a first byte. That isolates the fault to the application tier behind the proxy.

The pre-failure window shows a monotonic TTFB ramp — 190 → 480 → 1,240 → 2,900 ms over roughly four minutes — rather than a step change. A process crash, OOM kill or restart produces an abrupt transition from healthy to connection-refused; progressive queueing produces a ramp. The terminal state is HTTP 503 with a well-formed response body (responseSize 214 bytes, consistent across regions), which is a proxy or application rejecting requests under load, not an absent listener. Confidence is medium rather than high because Pingara observes only response timing; it cannot distinguish a saturated connection pool from a saturated thread pool or a downstream dependency queue.

TTFB baseline moved from 190 ms to 243 ms at a discrete point (T-41m), simultaneously in all three regions, and never recovered. A simultaneous cross-region shift with no corresponding change in DNS, TCP or TLS timing is a property of the origin, not of any one network path, and a step-and-hold shift is the signature of a deployment rather than of load. Pingara has no deployment visibility; this should be checked against the service's change log before it is treated as established.

Evidence against: all three regions failed within 95 seconds of one another with identical timing signatures (ttfb 5,001 ± 6 ms) and an identical status code. A provider-side fault would be expected to affect regions non-simultaneously and with divergent timings, and the three probe regions do not share a failure domain. The correlated, identical failure points at the shared origin rather than at three independent networks.