Landing Page Outage: When Can You Restart Meta Ads?
If your landing page or checkout breaks, stop sending paid traffic into the confirmed failure. Resume only after the affected buying path works and somebody owns the next spend decision. A homepage that loads is not enough. I want the exact ad destination, offer, checkout or signup route, and measurement checked together.
For an AI/SaaS or ecommerce brand spending at least $15,000 a month on Meta, the useful question is simple: what can you safely send traffic to now? Here is the incident record I would build, the exposure calculation I would use, and the evidence I would require before restarting.
Contain the failure you can reproduce
Open the exact destination used by the affected ads, including its campaign parameters. Record the failing step, device, browser, market and time zone. Save the error and the last known working observation. Separate the first confirmed failure from the moment somebody noticed it; they may be hours apart.
Map that destination to the ads sending people there. If the checkout is broken across the store, the affected scope is broader than one product page. If only one signup route fails, verify the other routes before treating the entire account as down. Pause the affected delivery you control and record the action time. Check actual delivery afterward rather than assuming the requested pause stopped all exposure instantly.
Give the repair to a named technical owner and the traffic decision to a named account owner. Preserve the previous configuration. An untested redirect can replace a visible error with a wrong product, lost campaign tags or a different offer. Use an alternative destination only after checking the complete path and the ad's promise against it.
Calculate spend exposure without inventing lost sales
This is a hypothetical incident, not a client result. Suppose the affected campaign had a planned daily spend of $1,200, and your first estimate puts the outage at two hours. A uniform-spend model gives $1,200 ÷ 24 × 2 = $100 of estimated exposure. It is a planning estimate, not an upper bound: actual delivery can be uneven.
Now replace that assumption with the records available. In this example, the last successful check was 09:50, the first confirmed failure was 10:10, and delivery stopped at 12:10. The unknown start creates a range. Assume the spend ledger below covers only ads using the affected path, and the defect persisted after the first failure.
| Window, same time zone | Hypothetical recorded spend | What it establishes |
|---|---|---|
| 09:50–10:10 | $18 | Possible exposure before the first confirmed failure |
| 10:10–12:00 | $126 | Spend during the confirmed failure window |
| 12:00–12:10 | $9 | Additional spend before delivery stopped |
| Combined | $135–$153 | Window-based exposure range, subject to the stated scope |
The lower figure is $126 + $9. The upper figure adds the uncertain $18. Use this precision only if your records support those intervals. With hourly reporting, retain the wider boundary uncertainty; don't manufacture minute-level delivery from a daily total.
Neither $100 nor $153 is proven lost revenue. Some people may return later, some may reach an unaffected path, and many would not have bought anyway. To investigate business impact, join affected sessions and actual customer outcomes where you can. Keep expected orders, observed orders, spend exposure and contribution in separate fields. Do not multiply the exposure by yesterday's ROAS and report the result as sales lost.
Make the repaired journey pass an acceptance check
I would write the expected result before testing. “The developer deployed a fix” describes work completed. “The advertised variant reaches checkout at the promised price on the affected mobile browser” describes something you can verify.
| Check | Evidence to retain | Reason to keep affected traffic paused |
|---|---|---|
| Exact ad destination | Correct page and parameters, tested on the previously failing device | Error, wrong redirect or broken primary control |
| Offer and availability | Advertised product or plan, price and eligibility match | Unavailable variant or promise the buyer cannot obtain |
| Checkout or signup | Controlled end-to-end result, including the downstream order or account record | Payment path, account creation or required handoff still fails |
| Measurement | Intended event and corresponding business record agree in the authorized test setup | Known duplicate, wrong value or missing critical record |
| Production readiness | Released version, live configuration, owner and reversal path recorded | Test-only configuration remains active or rollback is unowned |
Use the payment provider's supported testing setup. Shopify's test-order guidance describes simulated orders and warns that customers cannot place live orders while payment providers are in test mode. Coordinate that check with the store owner and verify the live configuration afterward. Don't casually switch a trading store into test mode.
Stripe's testing documentation uses sandbox transactions that do not move funds, with test keys and test payment details. A successful sandbox payment is evidence about that test integration; it does not establish that the production configuration is correct. Verify the deployed settings and public journey separately without creating unauthorized charges.
Retest the original failure and the adjacent steps the repair touched. For a tracking-only incident, distinguish a working checkout with impaired reporting from a broken purchase path. The account owner still needs an explicit decision about what evidence supports continued spend while reporting is repaired.
Restart with a decision time and a stop condition
Write down which destinations passed, which remain paused, who can resume delivery and when the next review happens. Choose the initial exposure from the money you are prepared to risk while observing recovery. There is no universal restart percentage that fits every account.
In the hypothetical incident, I might authorize a first review after $60 of additional actual spend or 30 minutes, whichever comes first. That is an illustrative manual review trigger, not a hard platform spending cap or a promise that spend cannot overshoot between checks. Keep an owner watching actual delivery and stop again if the original failure returns.
That first review tests operational recovery: pages load, the offer works, and records arrive as expected. Thirty minutes without purchases does not prove a campaign has failed. Evaluate acquisition performance later using the account's conversion delay and a comparable observation window. Avoid changing creative, targeting and the offer during the repair unless one of them caused the incident; otherwise you lose a clear record of what changed.
Close the incident with evidence and ownership
Keep one record with the incident window, affected routes, pause and resume times, release version, exposure estimate, completed tests, unresolved issues and next review. If the start time remains unknown, leave the range visible. Assign any recurring monitoring or fallback work to a person with a due date.
For a continuing conversion problem, use my Facebook ads conversion diagnosis. For the remaining repair backlog, use the post-audit prioritization matrix. This incident record gives those investigations a clean starting point.
In my BFCM work for one US jewelry brand, I prepared the offers, creative and scale-or-cut decisions before managing $544,397.42 in Meta spend. Budget decisions need preparation and a person responsible for the next move.
If your account already spends $15,000 a month or more and the ads, destination and tracking need a joined-up review, bring them to me. My Meta ads audit covers the account and funnel with a prioritized action list. Schedule a call. You speak directly with the person who runs the account.