When a campaign breaks: an AdOps incident checklist

An ad points to the wrong product. A conversion event stops appearing. Spend jumps after a configuration change. These incidents need different fixes, but they share an operating problem: several people may start changing things before anyone establishes what happened.

A useful incident process should help the team act quickly while keeping the diagnosis readable. It does not need a long meeting or a complicated form.

Start with one clear incident record

Record the observed problem, affected campaign and creative IDs, first known failure time, last known good state, and who is coordinating the response.

Separate observations from explanations. “The mobile landing page returns an error” is an observation. “The publisher broke the link” is a hypothesis until the evidence supports it.

Estimate the scope using available data. State what is confirmed and what is still being checked. If reporting is delayed, do not treat a partial number as the final impact.

Contain the specific problem

Choose the least disruptive action that addresses the confirmed risk and falls within the operator’s authority.

A wrong destination may require pausing the affected creative or switching to an already approved replacement. A suspected reporting delay may call for investigation before pausing otherwise healthy delivery.

If the defect appears across a shared template or destination, broaden the containment accordingly. Avoid assuming that fixing one visible ad fixes every placement using the same source.

Record the action, time, previous value, and person responsible. Use an agreed approval path for changes outside existing authority.

Preserve enough evidence to reproduce it

Before replacing a configuration, save the relevant IDs, settings, error message, and test result. Capture the environment: device, browser or app, consent state where relevant, and the exact destination or affected event.

Do not paste account secrets or customer data into a group chat. Share a redacted example and keep detailed logs in the approved location.

The ad tag inspector can help examine a supplied tag without executing it. For a live playback problem, collect the player evidence described in the VAST troubleshooting guide.

Give each proposed change an owner

Use a small action table during the incident:

Action	Owner	Evidence of completion
Confirm affected placements	Campaign operator	List of IDs and shared dependencies
Correct the approved destination	Destination owner	Saved value and tested URL
Verify the replacement	QA owner	Reproducible test result
Resume the affected delivery	Authorized operator	Active state and monitored sample

These roles can belong to the same person on a small team. What matters is that an action is not assumed complete because someone said they were looking at it.

Avoid simultaneous unrelated changes. If several changes are essential, record them separately so the recovery can still be explained.

Verify recovery where the failure occurred

A successful save is not enough. Repeat the original failing case, check a representative sample of affected placements, and confirm that the intended measurement events appear.

Watch the system for a period appropriate to its reporting delay. A fixed landing page can be checked immediately; processed conversion reporting may need longer.

Communicate what is restored and what remains uncertain. “The destination now passes the mobile check; reporting impact is still being reconciled” is more useful than declaring everything resolved.

Close with a prevention step

Once the incident is contained, document the cause, affected interval, best supported impact estimate, and any remaining corrections.

Choose a specific prevention step: validate the shared URL template, add an owner to a handoff, or require a read-back after changing a setting. Add it to the campaign launch checklist or the relevant operating procedure. The purpose of the record is to make the next launch and the next response easier.