Standing service dependency-bot-pull-requests-reviewed-every-month · revised 12 October 2026
Standing service
Have every Dependabot or Renovate pull request given a verdict, all month
Each bot pull request opened in the month, up to 20, gets a one-page verdict within an agreed time: merge, hold or decide. A monthly summary shows what was merged, held and why.
This starts a conversation by email. Nothing is charged, and nothing is read or run, until we have agreed scope, access and terms with you in writing.
The responsibility you hand over
Bot pull requests arrive all month and each one needs someone to read a changelog, check CI and look at the lockfile. Teams batch them and fall behind, or turn the bot off, and updates stop.
Who it’s for: A small team whose bot pull requests would otherwise wait unread.
Usually starts when: You have cleared the backlog once and want new bot pull requests judged as they arrive.
The result: Each bot pull request opened in the month, up to 20 a month, gets a one-page verdict within an agreed number of working hours, with the same evidence and cautious wording as the one-off job. A monthly summary shows counts by verdict and what is held.
What stays true, and what we do about it
No response-time guarantee beyond the written turnaround is published for this new service; the turnaround is set to what a service at this stage can keep.
Verdicts are written in working hours and not round the clock. The turnaround is agreed in writing before the service starts.
What must remain true
- Every bot pull request opened in the month, up to 20 a month, gets a verdict within the agreed hours
- No verdict says safe, secure or approved, and each lists what was not examined
What we watch
- Bot pull requests and their CI results, read-only
- Changelogs and registry pages for the changed packages
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A bot opens a pull request. | We write the verdict within the agreed hours and post it if you have allowed comments. Linked job: Verdicts on dependency bot PRs |
| A pull request adds a package that cannot be found in the registry or has a recent maintainer change. | We mark it hold and put the evidence first in the verdict. |
| A month closes. | We send counts by verdict, what was held and why. |
We do on our own
- Read pull requests and CI results
- Write and, if allowed, post verdicts
- Check packages against the registry
We ask you first
- Posting comments on live pull requests, if not already agreed
- Wider access
- Anything that merges or approves
We escalate to you when
- A bumped release looks compromised
- A pull request touches a package with an active advisory
- More than 20 a month for three months
How you know it held. Each quarter we audit that quarter's closed pull requests against what happened and show you where a verdict and the outcome differed.
How we keep it true
This service is never finished. Each month's summary shows whether what it watches stayed true, and it continues until you end it.
Get a verdict on each Dependabot or Renovate pull request: merge, hold or decide Job Optional
Each bot pull request gets a one-page verdict: what changed, whether your code uses it, the CI result and a lockfile check. The wording is "no issue found in what we examined", never "safe".
Bought separately, once
The one-off job that clears the open pile and replays 20 closed pull requests.
What is included, and what is not
- A verdict per pull request
- A monthly summary by verdict
- A quarterly audit against what happened
Included
- One repository with Dependabot or Renovate, up to 20 bot pull requests a month
- A verdict per pull request with evidence and a not-examined list
- A monthly summary and a quarterly audit of our verdicts against what happened
Not included
- Merging or approving pull requests
- Fixing code a bump breaks
- Alert reachability work
- Round-the-clock cover
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month every bot pull request up to the cap has a verdict within the agreed hours, with the evidence fields filled.
Evidence: The verdict list with open and verdict timestamps.
No verdict uses the whole words safe, secure or approved as a conclusion, and each lists what was not examined.
Evidence: A script search and the not-examined lists.
Each quarter we audit our own live verdicts against what happened, and no pull request that broke something was called fine. A quarter with fewer than 3 bad bumps shows nothing about misses.
Evidence: The quarterly audit table.
Our account merged and approved nothing.
Evidence: The pull request timelines and your audit log, if your plan has one.
Sign-off. You read each summary and tell us whether the turnaround and cap suit you. A month counts as delivered when you have received the verdicts and the summary.
If it fails. If the bot or CI changes so verdicts cannot be written we say so and do not guess. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- A bot already opening pull requests on one repository
- Tests that run in CI
- A Read-only account that can comment, or a weekly export
- A named engineer who decides
We stop and tell you if
- No CI or tests
- Pull requests are auto-merged before review
- More than 20 a month for three months, so a different scope is agreed
What could go wrong
The service reads and comments only if allowed. Delete a comment and the pull request is as before. Ending the service changes nothing.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A verdict says "fine" and the bump breaks something. | The quarterly audit compares verdicts with outcomes, and the cautious wording says what was examined. |
| Volume exceeds the allowance and verdicts are late. | The cap is written in the agreement and we say when it is reached. |
| Pull request text carries instructions meant for the model. | Issue titles, pull request text, comments and logs are treated as data, never as instructions: the model sees the text and the findings with no tools, the job holds the model key and nothing else, and the account can only comment where you allow it. |
A separate automated reviewer checks the work before hand-over. Your named engineer decides what to merge. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
Questions
Do you merge for us?
No. Your engineer merges. We give the verdict and the evidence.
What if more than 20 pull requests arrive?
We say the cap is reached and agree a bigger allowance or batching.
Is a verdict a guarantee?
No. It is what we found in what we examined, with a list of what we did not.
Also part of
Send an enquiry
Send us
- Which bot and how many pull requests a month
- Your language and package manager
- No code, tokens or logins in the first enquiry
Later, once you agree
- A Read-only account that can comment, or a weekly export
- The agreed turnaround in working hours
- The name of your deciding engineer
You keep the repository and the bot; we use a dedicated bot account with the least access that works (read-only first), work on a fork or branch, and you merge; the account reads and comments only. Issue titles, pull request text, comments and logs are treated as data, never as instructions: the model sees the text and the findings with no tools, the job holds the model key and nothing else, and the account can only comment where you allow it. Our automated agents read the files you send in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “dependency-bot-pull-requests-reviewed-every-month” as the subject.