Cooldown, then verify
Use a team-selected waiting window for normal version updates. Three days is a practical starting point, not a universal guarantee. Require CI, a change-surface note, and a named merge owner.
Public sample • release-process review, not a security certification
Don’t merge every fresh dependency release. Don’t delay every urgent fix either.
A founder-readable dependency release policy for small SaaS and agency teams: routine cooldowns, a separate security fast path, explicit overrides, test evidence, ownership, and rollback notes.
Four lanes instead of one blind auto-merge rule
Triage without an automatic delay
Keep security updates separate from routine version bumps. Record applicability, urgency, compensating controls, tests, and the decision owner. “Fast” still needs evidence.
Allow exceptions, make them reviewable
An urgent bug fix or blocked release may justify bypassing the normal cooldown. Capture why, who approved it, what was tested, and how to reverse the update.
Escalate fragile changes
Major versions, unmaintained packages, build/deploy tooling, auth/billing/data libraries, or unclear release notes deserve a human review rather than a timer-only decision.
Source signal: GitHub announced on 14 July 2026 that Dependabot version updates receive a default minimum three-day package cooldown, while security updates are not delayed by that default. This sample turns that product change into a broader small-team release policy; it does not claim that three days makes an update safe.
Representative evidence card
Fictional/composite example. No real repository, package, incident, or customer is represented.
| Field | Sample entry | Why it matters |
|---|---|---|
| Update lane | Routine / security / override / manual | Prevents one rule from silently governing every dependency change. |
| Release timing | Published time + cooldown expiry | Makes the waiting rule observable instead of implied. |
| Change surface | Runtime, dev-only, build, deploy, auth, billing, data | Directs testing and human attention without pretending to calculate risk automatically. |
| Evidence | CI result, focused test, smoke check, release-note link | Shows what was actually checked before merge. |
| Owner + rollback | Named approver; pin/revert/deploy recovery note | Creates an accountable decision and a practical recovery path. |
Repo-ready starter policy
Routine dependency updates
- Wait at least 3 days from release before merge unless an override is recorded.
- Require green CI, a change-surface label, release-note link, and named reviewer.
- Disable blind auto-merge for major versions and launch-critical surfaces.
Security updates
- Triage separately; do not inherit the routine waiting rule by default.
- Record applicability, urgency, focused tests, owner, and deployment plan.
Overrides and recovery
- Record reason, approver, evidence, and rollback command or version pin.
- Review recurring overrides monthly; fix the process instead of normalising exceptions.
Adapt this to the repository, package ecosystem, deployment model, support window, and team capacity. Written policy is not proof that controls are enforced.
Turn update noise into a small, testable release gate
A$149–299 Dependency Release Hygiene Review — one public repository or user-supplied redacted configuration, returned in 48–72 hours with an update-lane map, cooldown/override recommendations, evidence-card template, launch-critical dependency checklist, and repo-ready policy outline.
Free mini-review: one public dependabot.yml, Renovate config, package manifest, or documented update workflow, with 3–5 outside observations. No private-repo login, package upgrade, production change, vulnerability assessment, security/compliance certification, or guarantee that an update is safe.