A single threshold on a single window cannot separate a real outage from a brief spike, so it either pages on noise or misses slow burns. Replace it with multi-window multi-burn-rate alerting: a fast rule that pages and a slow rule that files a ticket, each gated by a short window so a spike that already stopped does not keep paging.
A partial index only contains rows matching its predicate, so indexing WHERE deleted_at IS NULL stores five million entries instead of forty million - smaller, shallower, and far likelier to stay cached. The catch is the planner only uses it when it can prove the query predicate implies the index predicate, and it does nothing about dead rows still in the heap.
CPU is compressible, so the kubelet throttles it rather than evicting for it. Eviction comes from memory, ephemeral storage or inodes - and which pods die is decided by QoS class, not by who caused the pressure. Check node conditions and eviction thresholds first, then fix the requests and limits so critical workloads are Guaranteed rather than BestEffort.
This is write skew: two transactions read the same set, each writes a different row, and the pair commits a state neither would have produced alone. No row-level constraint can catch it because the invariant is a property of the set, so the fix is either serializable isolation, a lock on something both transactions must touch, or remodelling the invariant onto a single row.
Name the clock and what it was costing, say which facts you had and which you chose not to wait for, classify the call as reversible or not, act at the level you were authorised to and say so, and record the reasoning at the time so it can be judged on what you knew.
Stabilise first and diagnose second, which usually means reverting the change before you understand it. Take one artefact of evidence on the way out, time-box the decision aloud, communicate impact on a fixed cadence, and treat the incident as open until the damage the deploy caused is repaired.