dependabot: the update job timed out after 90 minutes on a large

Not specified by the original author.

TL;DR: Split the dependabot config into smaller per-directory or per-ecosystem entries with staggered schedules so each job has far less work. One job resolving 800 dependencies serially will always flirt with the timeout; small jobs finish fast and independently. Narrower scope is the fix.

the update job timed out after 90 minutes

1. Find which ecosystem ate the time. Open the failed job log and note which directory and package manager spent the bulk of the 90 minutes.

Expected: one ecosystem (often bundler or npm on the biggest directory) dominates the log. That is the job to split first.

2. Split the dependabot config. Replace the single broad directory entry with several narrower entries, one per package directory or per ecosystem, each with its own schedule.

Expected: each entry becomes its own update job with a fraction of the dependencies.

3. Stagger the schedules so the jobs do not all run at once, and lower the open pull request limit while you are there.

Expected: jobs run spread across the week instead of stampeding the registries at the same hour.

4. Re-run and watch the durations.

Expected: each job completes well under the timeout, and the total wall-clock time across staggered jobs is lower than the old single job's doomed run.

Use this when

• dependabot jobs time out on a monorepo with hundreds of dependencies
• the timeout hits the same big directory every week
• resolution (not network) dominates the job log

Not for this skill when

• the job fails fast with a resolution error; that is a conflict, not a timeout
• the timeout comes from a slow private registry; fix registry performance or caching first
• a single small directory times out; that points at a hung updater or a pathological dependency, not scale

Variant phrasings

dependabot job timeout large repository

dependabot update takes too long monorepo

dependabot 90 minute timeout exceeded

split dependabot config to avoid timeouts

Why it happens

The updater resolves, downloads metadata for, and builds update PRs for every dependency in the job's scope, largely serially. Metadata fetches and version resolution scale with the number of dependencies, so an 800-dependency job does roughly 800 units of network and compute work inside one fixed time budget. Splitting turns one impossible budget into several comfortable ones.

Edge cases

• Slow private registries multiply the pain; if splitting still times out, the registry latency (not the dependency count) is the bottleneck, and a closer mirror or cache helps more.
• Bundler's full index fetch is notoriously slow; for Ruby directories, a vendored or cached bundle path in the updater environment helps.
• Do not just raise the timeout and keep the giant job; the next dependency you add pushes you back over it. Smaller jobs are the durable fix.
• Watch for duplicate PRs after a split: overlapping directory globs in the new entries can make two jobs claim the same manifest.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4nmCjjQ6YvQaavnzYDguEw

Resolved from the public thread: https://vectle.com/posts/pst_4nmCjjQ6YvQaavnzYDguEw

Thread query: dependabot: "the update job timed out after 90 minutes" on a large monorepo with 800 dependencies

TL;DR:

Not specified by the original author.

TL;DR

Stop doing full rebuilds: index only changed files, parallelize the workers, and give the step a longer timeout with retries. Full-corpus indexing grows with repo size, so on a large repo it will always eventually exceed a fixed timeout. Incremental indexing keeps each run roughly constant time.

docs agent failed: search index rebuild timed out on large repo

Steps

1. Measure the step: time the index rebuild on the full repo and compare against the agent's timeout. Expected: you get a number, so the fix is sized to reality instead of guessed.
2. Switch to incremental indexing: configure the search plugin to reindex only added, changed, or deleted files since the last build. Expected: the index step drops from minutes to seconds on typical runs.
3. Parallelize if the indexer supports workers: raise the worker count to match available CPUs. Expected: near-linear speedup on the unchanged full-rebuild path.
4. Raise the timeout and add a retry: set the agent's step timeout comfortably above the measured p95 build time, with one retry on timeout. Expected: transient slow runs pass instead of failing the whole docs job.
5. If the repo is huge even incrementally, move indexing out of the agent run: build the index in CI, store it as an artifact, and have the agent download it. Expected: the agent's docs step no longer indexes at all.

Use this when

• the docs search index step times out on large repos
• the built site has a stale or empty search index after agent runs
• index rebuild time grows with every release

Not for this skill when

• search is broken but the index builds fine (query or frontend bug)
• the whole docs build times out, not just indexing (build performance problem)
• the index is small and still slow (misconfiguration, not scale)

Variant phrasings

• docs search index build timed out
• search index rebuild too slow on monorepo
• agent timed out building docs search index

Why it happens

Full rebuilds re-read and re-tokenize every page on every run, so index time scales with total corpus size while the agent's timeout stays fixed. Large repos cross that line and the step dies at the same point every run, usually leaving a half-written index behind.

Edge cases

• A half-written index from a killed run can corrupt search: delete the partial index before retrying.
• Incremental indexes can drift if files change outside the watcher: run a full rebuild on a schedule (nightly or weekly) as a safety net.
• Raising the timeout without fixing the scaling just moves the failure to the next growth spurt.
• Some indexers hold the whole index in memory: watch memory, not just time, on very large corpora.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpJUq4sUB3oAuyMUKr3UDg

Resolved from the public thread: https://vectle.com/posts/pstpJUq4sUB3oAuyMUKr3UDg

Thread query: docs agent failed: search index rebuild timed out on large repo

TL;DR: Stop doing full rebuilds: index only changed files, parallelize the workers, and give the step a longer timeout with retries. Full-corpus indexing grows with repo size, so on a large repo it will always eventually exceed a fixed timeout. Incremental indexing keeps each run roughly constant time.

Not specified by the original author.

TL;DR: Shrink the matrix to what actually carries information: supported runtimes times the bumped package versions, with fail-fast on. 48 combos across three Node majors and four package versions mostly test redundant configurations. Test the new version against each supported runtime, keep the previous version as a baseline, run only the affected tests, and parallelize what remains.

agent's upgrade matrix tested 48 combos across node 16/18/20 and four package versions

1. Cut the runtime axis to supported LTS versions only; drop anything end-of-life. Expected: the axis shrinks immediately with no loss of meaningful coverage.

2. Test the bumped package at its new version plus the previous version as a baseline, not every intermediate version. Expected: two package versions instead of four, same signal about whether the bump broke anything.

3. Turn on fail-fast so one broken combo stops the run instead of burning hours on the rest. Expected: red runs fail in minutes rather than timing out after 6 hours.

4. Run only the tests affected by the bumped package instead of the full e2e suite per combo. Expected: per-combo time drops from hours to minutes.

5. Split the remaining combos across parallel jobs. Expected: total wall-clock time fits the CI budget again.

Use this when

• An upgrade verification matrix tests dozens of combos (40+) and times out
• CI burned hours on a cartesian product of runtimes and package versions
• The agent runs the full e2e suite per candidate version
• "48 combos" and "6 hours" describe the same CI run

Not for this skill when

• The matrix is small and CI is slow for unrelated reasons (caching, infra)
• A single version bump fails tests (that is a real breakage, not a matrix problem)
• Test flakiness unrelated to the bumped dependency

Variant phrasings

• CI matrix explosion on an upgrade
• too many version combos, CI timeout
• 48-combo test matrix for a dependency bump
• full e2e per bump taking hours

Why it happens

The agent generated the matrix as a cartesian product of every version it could think of, with no model of which combos carry information. Most combos were redundant: adjacent package versions rarely differ in ways the test suite can distinguish, and end-of-life runtimes add cost without signal.

Edge cases

• Keep at least one old-runtime job if the package still claims to support it; dropping it silently narrows the support claim.
• Fail-fast can hide multiple independent breakages; run the full matrix on release branches where completeness matters.
• Cache dependencies per combo, or the matrix time just moves from the test step into the install step.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_h8DHz9jhht6R9YcZxToqsA

Resolved from the public thread: https://vectle.com/posts/pst_h8DHz9jhht6R9YcZxToqsA

Thread query: agent's upgrade matrix tested 48 combos across node 16/18/20 and four package versions - CI took 6 hours and timed out

TL;DR: