Schedule, retry or timeout change that multiplies load
Schedules run more often, retries added without backoff, timeouts raised, CI concurrency that does nothing.
Why it matters
When a job misses data or a call fails intermittently, the quick fixes are to run the job more often, retry more times, and wait longer. An agent reaches for the same levers, and each one is a one-line change that makes the immediate symptom go away.
Each one also multiplies load. A cron that runs thirty times as often does thirty times the queries and paid API calls whether or not anyone uses the app. Retries without backoff hammer a dependency that is already failing. A long timeout lets stuck requests hold workers until the pool runs out and unrelated requests start failing too.
Example
export const syncInventory = schedules.task({
id: "sync-inventory",
- cron: "0 * * * *",
+ cron: "*/2 * * * *",
run: async () => {
const client = new SupplierClient({
- maxRetries: 1,
- timeoutMs: 2000,
+ maxRetries: 6,
+ timeoutMs: 30000,
});
What it detects
- Cron expressions whose runs per day grow by more than 1.5 times. Renovate and Dependabot schedules are skipped, since those are permitted windows.
- Retry settings (maxRetries, retries, max_attempts and similar) raised, or newly set to three or more with no backoff or jitter anywhere in the file. Retry loops such as for attempt in range(3) around a network or database call, with a note when a Python loop runs at import time.
- Timeout values raised five times or more.
- GitHub Actions concurrency groups keyed on github.run_id, which is unique per run and therefore never cancels or coalesces anything. These are reported once across all workflows.
What to do when it fires
Confirm each new number is deliberate. For a job that is catching up on missed work, keep the old interval and let the job process a backlog. For retries, add exponential backoff with jitter and a retry budget, and give the whole operation one deadline.
Set timeouts close to the real p99 of the call and let the caller fail fast. For CI, key the concurrency group on the workflow and ref, such as ${{ github.workflow }}-${{ github.ref }}, and set cancel-in-progress on purpose.