How Zero Hour works.

This page is the full technical walkthrough of Zero Hour. If you've ever wanted to understand exactly what a Chrome extension does between the moment you click "Save snipe" and the moment your bid lands on eBay, this is for you.

The five-stage lifecycle of a snipe

Stage 1 — You save the snipe

You're on an eBay auction page, or you've pasted a URL into the Zero Hour popup. The Add Snipe sheet shows the item with current price, end time, and a max-bid input. You confirm and tap Save.

What happens locally:

• The snipe is persisted to chrome.storage.local as a single object: { itemId, maxBid, leadTime, endTimeMs, ... }.
• The service worker registers a Chrome alarm: chrome.alarms.create('snipe-{id}', { when: endTimeMs - 30000 }).
• The popup updates to show the new snipe in the Active list.

No network request leaves your machine. Saving a snipe is a local-only operation.

Stage 2 — The 30-second wake-up

Chrome's service worker is normally idle between events. The chrome.alarms API is the only reliable way to wake it for scheduled work in Manifest V3.

At 30 seconds before your snipe's fire time, Chrome wakes the service worker. The worker:

• Reads the snipe back from chrome.storage.local.
• Looks for an existing eBay listing tab to reuse (keeps your Forter session warm) or opens a fresh background tab on the listing URL.
• Schedules a high-precision in-memory setTimeout for the actual fire time. Alarms are accurate to the second; setTimeout handles the sub-second precision once the worker is awake.

Stage 3 — Firing the bid

At T-minus-your-lead-time (default 3 seconds before close):

1. The service worker locates or opens a background tab on the eBay listing. Your session cookies and eBay's anti-fraud script load natively in that tab.
2. The bidder content script inside the tab fetches the bid-layer JSON to read the per-action srt tokens.
3. It picks up the live Forter risk token from the page context (eBay's anti-fraud SDK computes this from a browser fingerprint, so it must come from a real page, not a service-worker fetch).
4. It POSTs action=reviewbid then action=confirmbid to https://www.ebay.com.au/bfl/placebid (or the regional equivalent) as JSON with credentials: 'include' and redirect: 'manual' so any auth redirect is detected rather than followed.
5. Parse the response. A clean 200 with a confirmation payload is a win-pending. A 302 to /n/error is treated as auth-required so you can fix it before re-running.
6. If auth failed (cookie expired in the last second), surface it; we never silently retry a real-money action.
7. Update the snipe status in chrome.storage.local: won_pending, outbid, auth_required, or failed. If we opened the tab ourselves, close it.

Stage 4 — Confirmation

30 seconds after the auction's official end time, the worker fetches the listing's public page once more to verify the final result. If the snipe was marked won_pending and the public page confirms you won, the status becomes won and the winning price is recorded. If you were outbid in the closing seconds, the status updates to outbid.

Stage 5 — Notification

A Chrome system-level notification fires:

• Won: YOU WON — [item title] · Final $47
• Lost: Outbid — [item title] · Winning bid was $52
• Failed: Snipe failed — [item title] · Re-auth required

Click the notification to open the popup with the Completed tab pre-selected. On a win, there's a particle-burst celebration overlay.

Reliability hardening

Clock drift

The user's local clock can be off by several seconds. At extension startup, and once per day thereafter, Zero Hour fetches a trusted timestamp from zerohourbid.com/api/time and stores the offset. All snipe scheduling applies the offset.

Service worker suspension

Chrome may suspend the service worker between events. The 30-second-ahead alarm wake-up exists specifically to handle this. Even if the worker has been suspended for hours, the alarm wakes it in time to run the pre-fetch.

Multiple simultaneous snipes

If two snipes fire within the same second, the worker staggers them by 100ms to avoid rate-limit triggers. Bid POSTs are non-blocking, so the second snipe doesn't wait for the first to complete.

Cookie freshness

Cookies are read fresh every time a bid is placed. If they've gone stale between the pre-fetch (T-30s) and the fire (T-3s), the auth retry on failure catches it.

What this architecture cannot do

For transparency:

• Fire when Chrome is closed.
• Fire when your computer is asleep.
• Fire if you've uninstalled or disabled the extension.
• Survive a Chrome crash within the final 30 seconds. Chrome's own crashes are out of our control.

These are the structural costs of never trusting a third party with your credentials. We're upfront about them on the install screen and on every relevant page.

Why this is more reliable than people assume

The instinct is to assume server-side snipers are more reliable. In practice, both architectures hit similar real-world reliability numbers (97 to 99.5%) for different reasons:

• Server-side handles "computer off" but adds a network round-trip and a single point of failure (the sniper's servers).
• Client-side requires your computer to be on but eliminates the network round-trip and the server outage failure mode.

For users who snipe in the evening on a desktop or a laptop they can keep plugged in, client-side is at least as reliable. For users who snipe at 3 AM with the laptop closed, server-side has an unbeatable advantage.