Every indexing request failed today. The bug was my timezone.
My daily job was simple: open Google Search Console, paste in a URL, click Request Indexing, repeat for ten URLs, done. It ran every morning at 10:07 Beijing time. It had been working.
Then one morning every single request came back with the same popup:
Sorry! We are unable to process this request because you have exceeded your daily quota. Please try again tomorrow.
Zero accepted. Zero skipped as already indexed. Sixty-two URLs still sitting in the queue, untouched.
First assumption: the script broke
I wrote the automation myself — a headless browser that fills the inspect field, waits 24 seconds for Google's check to finish, clicks the request button, waits another 5 seconds, and verifies the result. My first instinct was that something in that flow had rotted.
It hadn't. The script did exactly what it was told. It typed the URL. It clicked. Google answered. The answer was just "no."
Nothing in my verification logic was wrong. I was checking for the wrong failure mode — I had accounted for "already indexed" and "not found," but never for "quota." So every attempt looked like a clean run with no URL removed.
The actual cause
Search Console's indexing quota resets per US Pacific natural day. That's a hard cutover at 15:00 Beijing time (during PDT).
Here's what my two runs looked like after conversion:
- Previous batch, submitted at 22:11 Beijing on Sept 22 → 07:11 PT, Sept 22
- That morning's batch, at 10:07 Beijing on Sept 23 → 19:07 PT, Sept 22
Same Pacific day. I had already spent that day's quota twelve hours earlier, from my own point of view "yesterday."
Being nineteen hours apart in local time means nothing to Google. It counts calendar days in one fixed timezone.
Why my schedule made it inevitable
A single daily job at a fixed Beijing hour is safe on its own. 10:00 Beijing today and 10:00 Beijing tomorrow land on two different Pacific days. No collision.
What broke it was a manual extra run. I'd kicked off an additional batch at 22:00 the night before, which landed early in Pacific day Sept 22. The next morning's automated run then landed late in that same Pacific day — after the quota was gone.
So: not a script bug, and not really a timezone bug either. A scheduling bug, exposed by mixing manual runs with automation.
What I changed
Three fixes, all cheap:
- Moved the job to 16:00 Beijing — one hour after the Pacific reset, so the quota is always full when it fires. Shift the run to after the reset rather than hoping the previous day left something behind.
- Taught the verifier to recognize the quota popup and stop immediately. Burning five attempts into a dead quota teaches you nothing and risks looking like abuse. Now it reports "blocked by quota," keeps every URL in the queue, and retries next cycle.
- Added a rule for anything touching "tomorrow": convert to Pacific first. If a service resets daily and doesn't tell you in which timezone, find out before you build a cron around it.
The last one generalizes furthest. Rate limits, daily quotas, usage caps, "resets at midnight" — if it's a daily window, it belongs to someone's midnight, and it's usually not yours.
The part I got wrong
I spent my first twenty minutes reading my own code, convinced there was a bug. The script was fine. The honest lesson: when an automated task fails after previously working, check the external system's state before you audit your own logic. Confirm the limit, the timeline, and the timezone first. Often the bug isn't in your code at all — it's in the calendar.
If you want a second pair of eyes on your site or your indexing setup: /