The worst time to discover what an automation pause button means is during an incident. It might stop new recommendations, stop scheduled jobs, or prevent future writes. It might have no effect on campaigns already running in the advertising platform.
An emergency runbook should make those differences explicit. It should also identify which conditions justify intervention. A tracking failure, an unauthorized change, and an ordinary day of expensive conversions require different responses.
This guide is a proposed operating process. Test it against the actual controls in your platform and vendor account before relying on it.
Define the incident before choosing the stop
Create a short list of concrete triggers. Examples include changes in the wrong account, spending outside an approved plan, an expired offer still being promoted, repeated unverified requests, or a tracking outage that makes the operator's inputs unreliable.
Separate those incidents from performance alerts. An elevated CPA can justify investigation without proving that automation is malfunctioning. If every disappointing hour triggers a restart, the team loses a stable baseline and may introduce more changes than it can evaluate.
For each incident class, name the owner, the fastest available control, and the evidence needed to confirm the incident. A customer support complaint may be a useful lead; the responder still needs to inspect the specific ad or destination involved.
Distinguish three kinds of stop
| Control | What it should stop | What may continue |
|---|---|---|
| Recommendation pause | New analysis or suggested actions | Existing campaigns and scheduled provider work |
| Execution pause | New changes from the operator | Ads already running in the platform |
| Delivery pause | Spending or serving for selected campaigns | Reporting, attribution, and unrelated campaigns |
Do not assume a vendor supports all three. Record the actual behavior you have verified. If an execution pause cannot cancel an in-flight request, the runbook needs a readback step after the pause to discover whether that request completed.
Also identify access revocation as a separate control. Removing a connection may stop future API access without pausing any ads. It can make investigation more difficult if the team has no independent account access.
Capture a small incident snapshot
Before making unrelated changes, record the account identity, affected campaigns, observed problem, discovery time, latest known correct state, and the relevant change-log entries.
For a spending incident, distinguish confirmed spend from expected future exposure. Do not present an average daily budget as an exact account-wide daily cap. Google's average daily budget guidance explains that daily spending behavior and budget settings are not interchangeable.
A useful incident note might say that Campaign A has spent an illustrative $340 today, that its current budget setting is $200, and that the team is checking the applicable spending behavior and recent changes. It should not call the difference “unauthorized loss” without understanding the platform rules and the approved plan.
Contain only the affected scope
Start with the smallest control that addresses the confirmed problem. If one campaign uses an expired promotion, pausing that campaign can be more appropriate than disabling an entire agency connection. If the operator is acting in the wrong account, the execution path may need to stop broadly while account scope is investigated.
The runbook should name who may choose broader containment. This matters when a response could interrupt a major promotion or affect clients unrelated to the incident.
The NIST AI Risk Management Framework provides voluntary guidance for managing risks across the use and evaluation of AI systems. It does not prescribe an advertising pause procedure. The containment process here is an application of risk-based operational judgment to campaign work.
Verify the stopped state
After applying a control, inspect the resulting state from an independent account view where possible. Confirm that scheduled work is paused, queued actions are accounted for, and affected campaigns show the intended delivery status.
Write down what is still unknown. A dashboard badge that says “paused” may describe the operator while the ads remain active. A request timeout may leave the final campaign state uncertain. These cases need reconciliation, not a reassuring summary that skips the uncertainty.
Use a short checkpoint sequence: action requested, response received, state read back, remaining work identified. The responder should be able to hand the incident to another person without requiring them to reconstruct that sequence from chat messages.
Investigate the cause before restarting
Separate the trigger from the cause. “Budget increased unexpectedly” is a symptom. Possible causes include a stale approval, an incorrect account mapping, a competing rule, a timezone misunderstanding, or a human change that the operator did not observe.
Check whether the failure is still possible under the proposed restart conditions. Turning the system off and on is not a correction if the same queued proposal or conflicting instruction remains active.
Preserve the original evidence while investigating. If the tracking system later backfills conversions, retain the report that the operator saw when it made the decision. Otherwise a future reviewer may mistake a decision made from incomplete inputs for a decision made from the final data.
Restart with a bounded task
A controlled restart should identify the corrected condition, the actions now permitted, the reviewer, and the next verification time. It can begin with read-only analysis or a single low-impact action family rather than immediately restoring the previous scope.
Review the first completed action through the same proposal, authorization, execution, and readback chain used during normal operations. Do not create an emergency shortcut that removes the control responsible for preventing a repeat.
Then close the incident with confirmed impact, unresolved estimates, the cause supported by evidence, the corrective action, and any policy change. Use the next weekly review to check that the correction held. Update the budget guardrails if the incident exposed a misunderstanding about spending authority. A runbook is complete when the team can stop the right thing, see what remains active, and explain the conditions for starting again.