Bill shock is the moment the AI invoice arrives and the number is far outside what anyone planned for. The instinct is to panic or to cut everything off. Neither helps. A spike has a source, and a systematic diagnosis finds it faster than a frantic one. Here is the hour-one playbook.
Step one: confirm the spike is real, not a billing artifact
Before investigating usage, rule out the boring explanations. Check whether the billing period changed length, whether a credit or discount expired, or whether a prepaid balance ran out and shifted you to standard rates. These account-level changes can look like a usage spike but require no engineering response. Confirm the spike is in actual token consumption before you go further.
Step two: find the day it started
Pull daily usage and identify the exact day consumption jumped. A spike almost always has a sharp start date rather than a gradual ramp. That date is the most valuable piece of information you have, because it lets you correlate the spike with everything that changed around it.
Step three: correlate with deployments and events
Look at what happened on or just before the spike date. A code deploy, a new feature launch, a large new customer onboarding, a change to retry or timeout settings, or a provider incident that triggered mass retries. The cause is almost always something that changed in that window. Line up your deploy log against the spike date and the candidate list gets short.
Step four: isolate the source by key or feature
If you have separate API keys per team or feature, this step is fast: look at which key drove the increase. If you share one key across everything, this is the moment you feel it, because you have to reconstruct attribution after the fact from logs. Either way, narrow the spike to a specific workload before trying to fix it.
Step five: decide contain or continue
Once you know the source, you have a real decision instead of a panic. If the spike is a runaway retry loop or a broken automation, contain it now: fix the retry logic, disable the workload, or roll back the change. If the spike is legitimate growth, a real new customer driving real usage, then it is not a problem to stop, it is a cost to plan for. The diagnosis tells you which.
Stopping the next shock before it prints
Bill shock only happens when the first time you see a number is at month end. The prevention is a spend alert that fires on daily anomalies, not a report that arrives after the money is spent. A threshold on day-over-day growth would have surfaced this spike within a day of the slope changing, while it was still small.
Shock is a function of surprise, not of size. A large but understood number is a budget line. A moderate but unexplained one is a fire drill. Build the daily visibility and you convert every future spike from the second kind into the first.