cross platformdiagnostic

Ads Not Delivering: A Zero-Spend Diagnosis Across Meta, Google, and TikTok

Zero reports, impressions, conversions, and delivery failure for a frozen scope: an evidence-first decision tree.

Last verified July 19, 2026

Direct answer

“Zero spend” is an observation, not a cause. Separate zero reported results, zero impressions, zero attributed conversions, and delivery failure. Freeze scope, time zone, IDs, and last-known-good export. Compare delivery data with report/API freshness, schedule, budget, payment, policy/verification, destination/feed, and incidents. A green status page does not clear an account; a blank report does not prove ads stopped. Use official route and restart only after delivery, measurement, finance, and access checks pass.

Who this is for

Fit: operators and executives managing high-spend Meta, Google Ads, or TikTok programs with no spend, impressions, reports, or attributed conversions.

Non-fit: not an appeal service, reinstatement promise, legal advice, or bypass guide. It does not diagnose from screenshots or prescribe universal bid, budget, or recovery fixes.

Decision model

Use four predicates, recorded separately:

PredicateWhat it meansWhat it does not prove
Zero reported resultsThe selected dashboard, report, or API returns no rows/results.That no ads served. A filter, time zone, object scope, freshness problem, or API/report failure may be involved.
Zero impressionsAn authorized delivery record for the defined scope shows no impressions.The reason. Scheduling, budget/payment, policy/verification, targeting, feed/destination, auction, regional conditions, or an incident can all remain hypotheses.
Zero attributed conversionsThe platform reports no conversions for its definition, window, and model.That there were no visits, leads, orders, or settled outcomes. Event loss, consent, deduplication, attribution-window differences, modeled reporting, or downstream failures may explain the gap.
Delivery failure for frozen scopeTwo dependency-distinct delivery signals show no serving for an authorized, eligible scope during an intended live window, after report freshness and configuration checks.A provider-side root cause, reimbursement, restoration, or universal platform outage.

Synthesis/inference: this diagnostic state machine pairs black-box symptoms with owned telemetry and preserves competing hypotheses; provider and user views can differ. [RS-S07][RS-S09][RS-S19]

Independence rule (Synthesis/inference): count failure paths, not views. Signals are dependency-distinct only when they do not share report backend, account scope/ownership, identity, payment, domain/catalog/feed, pixel/dataset, credentials/admin, vendor/token/automation, or policy exposure. Same-backend UI/API/export/second-admin views corroborate but do not establish state; unresolved sharing is unknown.

A compact decision tree:

NO SPEND / NO RESULTS OBSERVED
  |
  +-- Can the report/API be trusted for this scope and time window?
  |      NO -> quarantine the report; compare a raw delivery export, UI/API,
  |            and second authorized viewer. Do not call it delivery-zero.
  |
  +-- Does an authorized delivery record show impressions?
  |      YES -> delivery occurred; branch to billing, attribution, or reporting.
  |      NO/UNKNOWN -> check schedule, budget, payment, policy, verification,
  |                     targeting, destination/feed, and recent changes.
  |
  +-- Do two dependency-distinct signals show no serving for the frozen eligible scope?
  |      YES -> classify delivery failure for frozen scope; root cause remains unknown.
  |      NO -> delivery failure remains suspected/unproven; resolve shared dependencies
  |             or preserve the conflict.
  +-- Is there an account/region/product incident or provider notice?
         YES -> preserve evidence, use official route, avoid repeated edits.
         NO/UNKNOWN -> open one factual case if material; stop before risky changes.

Diagnostic or control sequence

  1. Open a factual record. Evidence/input: platform/surface, region/entity, IDs, message, first-seen UTC, time zone, and last-known-good export. Owner: incident lead/recorder. Action: record the symptom without a cause. Stop/branch: retrieve missing IDs, scope, or time before editing.
  2. Freeze the comparison window. Evidence/input: filters, attribution window, schedule, budget period, currency, and time zone. Owner: measurement owner. Action: define one cohort and preserve the query/export. Stop/branch: label differing windows/scopes “not comparable”; do not infer zero delivery.
  3. Test reporting before delivery. Evidence/input: raw export, dashboard, authorized API, query parameters, freshness, and second viewer. Owner: measurement owner. Action: compare UI/API and report/export for stale, missing, or filtered data. [PR-P09][PR-P18] Stop/branch: quarantine unavailable or contradictory evidence and preserve the conflict.
  4. Establish the served-delivery predicate. Evidence/input: impressions, clicks, cost, status, and frozen cohort. Owner: operations executor. Action: classify report-zero, impression-zero, or delivery observed. Stop/branch: if impressions or cost exist, route to attribution, billing, or reporting.
  5. Check intended eligibility and timing. Evidence/input: schedule, dates, time zone, budget/bids, targeting, approval, inventory, and change ledger. Owner: campaign owner. Action: identify a configuration explanation or record none. Stop/branch: do not change settings while state is unrecorded; stop if unauthorized or rollback is unclear.
  6. Check payment, policy, and verification separately. Evidence/input: notices, billing/transactions, authorization, verification requests, policy references, and region/entity. Owner: finance; asset/legal owner. Action: mark observed, clear, or unknown; use displayed first-party route/labels for the affected account and region. [PR-P03][PR-P04][PR-P05][PR-P10][PR-P11][PR-P13][PR-P14][PR-P15][PR-P16] Stop/branch: preserve records and use the official route for provider review.
  7. Check destination, feed, and event dependencies. Evidence/input: landing, catalog/feed, pixel/CAPI/Events API/tags, consent, deduplication, analytics, CRM, and backend. Owner: measurement/destination owners. Action: distinguish delivery-zero from downstream gaps. Stop/branch: if delivery exists but events/outcomes are absent, classify measurement/settlement risk and freeze instrumentation until one cohort is defined. [RS-S07][RS-S08]
  8. Check product, regional, and partner signals. Evidence/input: status/history, region/network, manager relationships, API/vendor logs, and customer symptoms. Owner: incident/partner owner. Action: compare dependency-distinct paths. Synthesis/inference: heuristic, not a statistical guarantee. Historical boundaries: Meta’s 2024 report covers login/Ads-surface disruption, not account spend loss [PR-P17]; Google’s August 2024 report covers data isolation, not universal serving loss [PR-P18]; Google’s March 2025 report says some campaigns stopped, with cause/scope unclear [PR-P21]; Cloudflare’s January 2025 U.S. TikTok DNS observation is infrastructure evidence, not Ads telemetry [PR-P22]. Stop/branch: restrict sharing and escalate for cross-tenant evidence; do not keep querying or distributing it.
  9. Classify delivery failure cautiously. Evidence/input: frozen delivery export, authorized views/API, configuration, payment/policy/verification, and provider/region signals. Owner: incident lead. Action: record “delivery failure for frozen scope” only when two dependency-distinct signals agree an eligible live scope did not serve. Shared dependency means “suspected” or “unproven.” Root cause remains unknown; blank report, green status, or anecdote is insufficient. Synthesis/inference. [RS-S07][RS-S19]
  10. Contain one reversible risk, then route officially. Evidence/input: authorization map, before-state export, suspect changes, and first-party route. Owner: asset owner approves; executor acts; recorder reads back. Action: pause/reduce only for plausible unauthorized activity, exposure, or unsafe automation; submit one factual case. Stop/branch: stop on unexpected read-back, expanded blast radius, or sensitive-credential requests. [RS-S03][PR-P03][PR-P07][PR-P10][PR-P13][PR-P15]
  11. Reconcile separate ledgers. Evidence/input: billed, served, attributed, analytics/events, backend-settled, bank/card, and agency records. Owner: finance/measurement owners. Action: match entity, IDs, period, currency, time zone, and cohort; record residuals. Stop/branch: do not reverse a legitimate balance because a report is empty; unauthorized, platform-balance, and agency-invoice branches differ. [PR-P11][RS-S08]
  12. Use an explicit restart decision. Evidence/input: provider notice/case, corrected configuration, access/dependency review, ledgers, event test, and before-state. Owner: asset, finance, and incident owners. Action: authorize a limited monitored restart. Stop/branch: no restart if ownership, payment authority, policy/verification, destination, event path, or rollback is unknown; green is not recovery. [RS-S03][RS-S07][RS-S09]

Restart acceptance checks

Do not mark the incident recovered until the owner records each applicable check:

  • Delivery predicate passes for the frozen scope; impressions and cost are observed where the restart intends serving.
  • Access, owner, partner, payment authority, policy/verification state, schedule, budget, destination, feed, and shared dependencies are reviewed.
  • Billed, served, attributed, analytics, backend, bank/card, and agency records are reconciled or residuals have owners and dates.
  • A test event or conversion follows the intended path into the defined record; consent, deduplication, and latency limits are documented.
  • Campaign/rule/automation state matches the preserved before-state, with no unexpected changes.
  • Restart is limited, monitored, reversible, and has a written stop condition.
  • Asset owner, finance owner, and incident lead sign scope, residual provider dependencies, and closure date.

This is an operating synthesis, not a provider recovery standard. [RS-S03][RS-S07][RS-S09]

Evidence to preserve

  • Incident ID, reporter, first-seen UTC/local time, region, legal entity, symptom, platform/product surface, account/portfolio/manager/campaign/ad IDs, labels/errors, request ID, and case ID.
  • Frozen query: date range, time zone, filters, attribution window, currency, object scope, export timestamp, and API/UI result.
  • Last-known-good/current exports, budget/schedule/status, creative/targeting, payment/policy/verification/feed state, and recent changes with actor, timestamp, old/new value, approval, and rollback.
  • Second-admin/API/status observations; customer/analytics/backend symptoms; billing, bank/card, agency, served-cost, attribution, and settled-outcome records.
  • Event samples, consent/matching/deduplication, destination/catalog/feed health, unavailable-data notes, every attempted action, read-back, approver, and stop decision.

Screenshots can orient a reviewer but do not replace exportable records. Preserve evidence when safe and feasible before revoking, deleting, relinking, or rebuilding shared objects, subject to privacy and retention rules; urgent authorized containment must not be delayed. [RS-S03][RS-S15]

What not to do

Do not call a blank report a delivery outage, a zero-conversion report a revenue loss, or status silence proof no incident occurred. Do not repeatedly edit, blindly widen targeting, rotate identity/payment, create replacement or rented accounts, use cloaking/anti-detect tools, forge documents, flood appeals, or reverse a legitimate balance. Synthesis/inference safety rule: these are not diagnostic remedies and can expand exposure or evade controls. Never give passwords, MFA codes, cookies, government IDs, payment data, browser data, remote access, or scripts to an inbound “recovery” contact. Meta has described fake restoration services and rented trusted accounts [PR-P07]; Google’s guidance is provider-specific [PR-P10][PR-P11].

When to escalate

Use self-service when one authorized owner can reproduce a known-scope symptom, no compromise/provider decision is pending, and one reversible action has clear rollback. Escalate through the platform route for suspension, payment/transaction, verification, policy, cross-tenant, or provider risk; escalate internally for security, finance, legal/privacy, multiple owners, shared dependencies, or missing evidence.

A specialist can organize evidence and acceptance checks; no specialist controls a provider decision. Do not promise timing, restoration, reimbursement, ROAS, or recovery.

Official-route use

Official route identities are source-locked: Meta review, business verification, failed payment, and status; Google Ads Status, suspension/appeal, and billing/payment; and TikTok Account Health/suspension, business verification, transaction appeals, and advertising policies. See the source appendix for exact first-party URLs and citation keys.

Before acting, an authorized owner must open the current first-party route for the affected account and region and follow displayed labels. Public pages establish route identity; they do not guarantee account-specific labels, eligibility, timing, document requirements, approval, or outcome. Retrieve provider incident objects or account case IDs for delivery loss; confirm refund/credit/support/retention terms with provider or contract owner.

FAQ

Is zero spend proof that ads did not serve? No. Test report freshness, filters, scope, and time zone against raw delivery data; zero reported results and zero impressions differ.

If impressions are zero, is the platform down? Not necessarily. Check schedule, budget, payment, policy/verification, targeting, destination/feed, region, changes, and incidents; delivery failure remains a hypothesis until dependency-distinct signals agree.

If attributed conversions are zero, should tracking change immediately? No. Compare delivery, event arrival, consent, deduplication, attribution window, analytics, CRM, and settled outcomes for one frozen cohort.

Does a green Meta, Google, or TikTok status page clear the account? No. It is one product-scoped signal, not dependency-distinct delivery proof; compare exports, authorized view/API data, and customer telemetry. [PR-P01][PR-P02][PR-P09][RS-S19]

What counts as recovered? Not a green dashboard or restored login alone. Require delivery, ownership/dependency review, finance reconciliation, an event test, staged monitoring, and signed closure. Synthesis/inference. [RS-S03][RS-S07][RS-S09]

Source appendix

All sources were accessed 2026-07-19. Before acting, an authorized account owner must open the current first-party route for the affected account and region and re-check mutable platform pages and account-specific routes.

KeySource title; author/publisher; publication dateURL
PR-P01“Status and outages of Meta business products”; Meta; live/undatedhttps://metastatus.com/
PR-P02“About Meta Status Page”; Meta Business Help Center; undatedhttps://www.facebook.com/business/help/1171568854968373
PR-P03“Request a review if you are restricted from advertising on Meta platforms”; Meta; undatedhttps://www.facebook.com/business/help/530209463124901/
PR-P04“Verify Your Business in Meta Business Suite”; Meta; undatedhttps://www.facebook.com/business/help/2058515294227817/
PR-P05“Fix a failed payment issue on Meta”; Meta; undatedhttps://www.facebook.com/business/help/268196136699959/
PR-P07“Meta Takes Legal Action Against Scam Advertisers”; Meta Newsroom; Meta; 2026-02-26https://about.fb.com/news/2026/02/meta-takes-legal-action-against-scam-advertisers/
PR-P09“History | Google Ads Status Dashboard”; Google; live/undatedhttps://ads.google.com/status/publisher/summary
PR-P10“Google Ads account suspensions overview”; Google Ads Help; current/undatedhttps://support.google.com/adspolicy/answer/9841640?hl=en
PR-P11“Billing and payment suspensions”; Google Ads Help; current/undatedhttps://support.google.com/adspolicy/answer/13704200?hl=en
PR-P13“About suspended ad accounts on TikTok”; TikTok for Business; updated June 2026https://ads.tiktok.com/help/article/account-suspensions?redirected=1
PR-P14“How to verify your business on TikTok”; TikTok for Business; updated May 2026https://ads.tiktok.com/help/article/about-business-verification?aadvid=72391499277
PR-P15“About transaction-related appeals”; TikTok for Business; updated July 2026https://ads.tiktok.com/help/article/about-transaction-related-appeals
PR-P16“TikTok Advertising Policies”; TikTok for Business; updated August 2025https://ads.tiktok.com/help/article/tiktok-advertising-policies?lang=en&redirected=2
PR-P17“Facebook And Instagram Hit By Massive Outage”; Roger Montti, Search Engine Journal; 2024-03-05https://www.searchenginejournal.com/facebook-and-instagram-hit-by-massive-outage/510267/
PR-P18“Google Ads Experiencing Outage Impacting Key Features [Updated]”; Matt G. Southern, Search Engine Journal; published 2024-08-01, updated 2024-09-19https://www.searchenginejournal.com/google-ads-experiencing-outage-impacting-key-features/523624/
PR-P21“Google Ads stop running for some advertisers”; Barry Schwartz, Search Engine Land; 2025-03-02, updated 2025-03-03https://searchengineland.com/google-ads-stop-running-for-some-advertisers-452864
PR-P22“The fall and rise of TikTok (traffic)”; João Tomé, Cloudflare Blog; published 2025-01-21, modified 2026-07-15https://blog.cloudflare.com/the-fall-and-rise-of-tiktok-traffic/
RS-S03“Cybersecurity Incident & Vulnerability Response Playbooks”; CISA; U.S. government; 2021 (PDF served from 2024 path)https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
RS-S07“Monitoring Distributed Systems”, chapter 6; Rob Ewaschuk, edited by Betsy Beyer; Google SRE; 2017https://sre.google/sre-book/monitoring-distributed-systems/
RS-S08“Service Level Objectives”, chapter 4; Chris Jones, John Wilkes, Niall Murphy, Cody Smith; Google SRE; 2017https://sre.google/sre-book/service-level-objectives/
RS-S09“Managing Incidents”, chapter 14; Andrew Stribblehill; Google SRE; 2017https://sre.google/sre-book/managing-incidents/
RS-S15“How Good is Your Data? Investigating the Quality of Data Generated During Security Incident Response Investigations”; George Grispos, William Bradley Glisson, Tim Storer; arXiv; 2019-01-11https://arxiv.org/abs/1901.03723
RS-S19“Characterizing User and Provider Reported Cloud Failures”; Mehmet Berk Cetin, Sacheendra Talluri, Alexandru Iosup; arXiv; 2021-10-23https://arxiv.org/abs/2110.12237
shield_with_heartAdsInfra

Contact AdsInfra

Send a message about this resource before making a high-impact change.