One request at a time
A single queue with exactly one call in flight. Requests start at least 60 seconds apart; if a provider sends Retry-After, the longer wait wins.
Milestone 3 · Scheduling & reliability
Runs itself at 2:00 a.m. Eastern. Tells you when it doesn't.
A GitHub Actions schedule that is DST-aware, a single polite request queue, and a run log you can audit — every call, every retry, every record.
Runtime estimator
The same arithmetic the pipeline logs before each run. Move the sliders to see how the target list affects the nightly window.
Requests
61
Estimated runtime
1h 00m
Starts
2:00 a.m. ET
Finishes around
3:00 a.m. ET
Share of the 5.5 h run budget18%
Run history
Every run, on the record
Status is computed, not assumed: a run is succeeded, degraded (some calls or records failed) or failed.
| Started (ET) | Status | Trigger | Requests | Spacing | Records | Duration |
|---|---|---|---|---|---|---|
Change detection
What changed since last night
Each record carries a content hash. When a price or registration status moves, a snapshot is kept — the raw material for "price goes up Friday" or "only 20 spots left" badges in your directory.
Safeguards
Built to be a good API citizen
Polite retries
Timeouts, 429s and 5xx errors back off exponentially (60 s → 15 min), and every retry counts against the same spacing and call budget.
Circuit breaker
Three consecutive failures pause that provider for the rest of the run, so one outage never hammers an API or delays the others.
Hard budgets
Every run has a call budget and a 5.5-hour time budget. The plan is estimated before the first call and logged with the run.
Idempotent storage
Records are upserted by stable IDs, so re-running a night is always safe. Price and status changes are kept as history snapshots.
Loud failures
A failed or degraded run opens a GitHub issue — which GitHub emails to you — and can post to Slack or Teams, with the reason. Nobody has to watch a dashboard.