Amazon ads note · Reading trap

Reading trap: the ad report shows zero on the 1st of the month

Report days follow the account's time zone. Ahead of it, the account's 'today' hasn't started yet.

1

The claim

“It's the 1st. I opened the ad dashboard for the new month and everything is zero. Spend zero, orders zero. Is the API broken?”

I lost a morning to this once. Nothing was broken.

2

The usual reading

When a report shows zero for a period you know had activity, the reflex is to suspect the pipeline: a failed sync, an expired token, a report that didn't finish. Then you start debugging code that works.

3

Premises, laid out

Every conclusion below rests on these. Reject one and you can see which conclusions fall with it.

The "it's broken" reading quietly assumes three things.

  • ❌The report's "today" is my today. It isn't. Amazon Ads reports draw the day boundary in the advertiser account's time zone. For my US accounts, that is US Pacific time. Your laptop's clock is irrelevant.
  • ❌Ad data arrives with a one-day lag, so zero means "not loaded yet." In my pulls, ad report data was close to real-time. I pulled the same account-time day three times over a few hours, and the running total grew each time. There was no fixed overnight delay.
  • ✅A zero should be explained before it is trusted. This one holds. It's why the trap is worth writing down.
4

How we take it apart

Free: conclusion + one screen

Conclusion: if you are in a time zone ahead of the account's, then for part of your day the account's "today" hasn't started yet. Ask the report for that day and it correctly returns nothing. On ordinary days you don't notice, because your date range also covers earlier days that have data. On the 1st of the month, "month to date" collapses to a single day that does not exist yet in the account's time zone — so the whole month reads zero. Nothing is missing. The report is answering exactly the question it was asked.

Figure placeholderTwo report queries side by side — one ending on the 31st, one ending on the 1st — returning identical totals, with a clock strip showing account time vs local time.

The full step-by-step decomposition, including how AI joins the reports, is in the course.

5

Evidence

Free: one example

Experience

On my own accounts, on the morning of a 1st (my local time), a query for the 1st alone returned zero rows, and a query for the 31st through the 1st returned exactly the same total as a query for the 31st alone — to the cent. Nothing was missing; the day simply hadn't started for the account yet.

6

What would prove this wrong

Free: one sentence

Disproof condition. If a query for a day that has already begun in the account's time zone returned zero while the account was spending, the time zone would not be the explanation, and I would look at the pipeline.

7

How you run it

Course only
In the course

Reproduce this on your own account

  • Step-by-step operations, including the AI prompts used to join reports
  • Query templates and the exact fields to pull
  • A checklist to rule out the common reading traps
  • The full disproof conditions and the failed cases
See what the course includes
8

Ledger status

Status: reading trap, confirmed on my accounts. Ad report days follow the account's time zone, not yours. Before you debug a zero, work out what date it is for the account.

Verdict Reading trap
TypeExperience
Last updated2026-10-12

Type, in detail: Experience.

Have data that says otherwise? Share a case. Reversals are published.

Get the notes by email

New notes and ledger reversals, nothing else.

Prototype: email service not connected