Announce automated fix PRs with a one page note that says what the bot will open, who reviews each kind, what stays manual, how to pause it and where to ask questions. Send it before the first PR lands. Developers who understand the rules tend to engage with bot PRs instead of ignoring them.
Why a note is worth writing
A bot that starts opening PRs without warning looks like noise. Developers close it, mute it or complain. The technical setting may be perfect, and adoption can still fail. Why developers ignore bot PRs, and how to fix that, is covered in why developers ignore bot pull requests. A clear announcement fixes part of that for the price of an email.
The five parts
1. What it does. One sentence. "A tool will open pull requests that update dependencies with known security fixes in repositories A and B."
2. What it does not do. Say plainly that it does not merge anything on its own, if that is true. For a new rollout, every category should start manual. Anything you plan to automate later can be announced later, with its own note.
3. Who reviews. Route PRs to code owners and say so. See codeowners for bot opened pull requests. Add the expected response time for each urgency lane from your policy.
4. How to control it. How to pause it for a release freeze, how to exclude a package, and how to stop it touching a branch you are editing. See how to pause automated fix PRs during an incident for pause mechanics.
5. Where to get help. One channel or one person. Tell developers that false alarms and noisy rules are welcome feedback.
A template you can adapt
Subject: Dependency fix PRs start Monday in two repos
What: a bot will open PRs that update packages with known
security fixes. Repos: payments-tools, docs-site.
What it will not do: merge anything. A person approves each PR.
Reviewer: the code owners of the repo.
Expected response: security fixes within the week; emergencies
are called out in the PR title and in chat.
Controls: add the label hold to pause a PR. Ask in the
team channel to exclude a package.
Questions: the platform channel, any time.
What to promise, and what not to
Do not promise "no breakage". Promise a process: PRs show the evidence, tests run, a human decides, and a rollback path exists. Do not promise a PR volume. Say that the first weeks will be busier because of backlog, and that you will adjust.
Follow up
After two weeks, send a short second note: how many PRs, how many merged, what you changed. Developers like seeing their feedback reflected. Keep the numbers honest and local to your team, not borrowed.
Make opt-outs real
If you offer a way to exclude a package, honour it, and record why. Silent opt-outs become hidden risk, so give each one an owner and a review date. See a never auto-update list with owners and expiry dates.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Should leadership sign off on the announcement?
If the bot touches customer facing services, yes. A short approval from the engineering lead avoids surprise later.
Do I need a separate note for each repository?
One note per rollout wave is enough, listing the repositories in scope.
Last reviewed: 19 October 2026.
