A broken lead form or tracking path can go unnoticed while dashboards still show visits and activity. When the team finally sees a discrepancy, it may not know when the problem began, which pages were affected, or whether a repair restored the real lead path.
A simple incident log turns an unclear interruption into a record the team can investigate. It should help people contain the immediate impact, restore the path, identify the affected time window, and capture a specific follow-up.
Define what belongs in the log
Use the marketing incident log for unplanned failures that affect campaign delivery, conversion paths, or measurement quality. Examples include a form that will not submit, a confirmation page that loops, a CRM handoff that stops, a tag that fires twice, or a landing-page change that removes a required field.
Keep a suspected security or personal-data incident in the organization’s security and privacy response process. The marketing log can reference the incident ID and record downstream campaign impact, but it should not become a substitute for breach handling or store unnecessary personal information.
Decide what deserves an incident record. A useful threshold is a real or plausible impact to a live customer path, a materially incomplete measurement period, or a change that needs coordinated repair and verification. A minor content correction with no affected path may belong in the normal work queue.
Capture the first facts before they disappear
Open a record as soon as a team has a reasonable basis to investigate. Use a unique ID and a single owner. Capture what is known, mark what is still uncertain, and update the record as evidence improves.
Record at least:
- detection time and first observed symptom, with the time zone or standard used;
- affected site, page, form, campaign, event, CRM path, or vendor;
- expected behavior and the behavior actually observed;
- who reported it and where the evidence is stored;
- the last known-good time or deployment, if known;
- likely user or reporting impact, with the evidence and uncertainty;
- incident owner, severity, next update time, and current status; and
- every repair, test, decision, and handoff with its time and owner.
Do not estimate lost leads as a fact if the system did not capture them. Record the affected period, known failed attempts, missing evidence, and how the team will reconcile what can be recovered.
Restore the path in a controlled order
First stop avoidable harm. Depending on the incident, that might mean pausing an affected campaign, reverting a page change, routing a form to a monitored fallback, or placing a clear contact option beside a broken form. Assign one person to coordinate the response and keep a current incident note where the people doing the work can find it.
Then test the complete user path, not only the browser event. Submit a controlled test through the live form and confirm the expected receipt in the CRM, inbox, or approved intake queue. Check the confirmation message, duplicate handling, routing, and consent behavior that applies to the form.
For tracking, use the relevant platform’s preview or debugging view to inspect which tags fire and what data they process. Google Tag Manager’s preview mode can show tag firing status and data in the debug interface. That evidence helps verify instrumentation; it does not by itself prove that the lead was delivered or handled by sales.
When recovery is confirmed, record the test, environment, person who verified it, time, and any remaining data limitation. If historical events or leads are missing, keep that gap visible in reporting rather than silently filling it with an estimate.
Close the incident with a useful follow-up
After the path is stable, write a short review while the sequence is still clear. State the trigger, what changed, how detection happened, what customers or reports may have been affected, what restored service, and which action would make a repeat less likely.
Focus on the process and evidence, not on assigning blame. A follow-up action needs an owner, a due date, and a completion check. Examples include adding a submission test after form edits, monitoring the CRM handoff, documenting a release rollback, or clarifying who checks the conversion event after a tag change.
Track time to detection and recovery, repeated incidents, affected form or tracking coverage, and whether preventive actions were completed. The count of incidents alone can mislead: a team that detects more problems may have better monitoring, and a low count may reflect poor visibility.
A one-page incident record
- Incident ID and title: ______
- Detected at, time zone, and reporter: ______
- Affected pages, forms, campaigns, events, and systems: ______
- Expected behavior and observed failure: ______
- Last known-good change or time: ______
- Observed user impact and evidence limits: ______
- Owner, severity, status, and next update: ______
- Response timeline and decisions: ______
- Repair and full-path verification evidence: ______
- Affected measurement period and reconciliation note: ______
- Follow-up action, owner, due date, and completion proof: ______
For a lead who cannot complete a submission, use the lead-form failure recovery guide. The pre-launch tracking QA guide covers checks to run before a campaign change reaches production.
If the same form or tracking failures recur, request a marketing diagnostic to review the monitoring and ownership path.
Related reading
Read the lead-form recovery guide for user-facing recovery, and the tracking QA guide for validation before launch.
Sources and scope
- Google SRE Book: Managing incidents — describes a coordinated incident owner, a live incident record, clear handoffs, and learning after recovery in software reliability work.
- Google Tag Manager Help: Preview and debug containers — explains how preview mode shows tag firing and data for testing a container configuration.
The incident-response source is a software reliability practice adapted here to marketing operations; it is not a standard your team is required to adopt. Use your organization’s security, privacy, and customer-communication procedures when an incident falls under them. Accessed October 8, 2026.
How did this article land?
Choose one reaction. You can change it anytime.