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

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: