What we found
Dependabot version and security updates never ran on any private repo under this account. On
ptr727/Financial-Modeling, every dependabot-updates and update-graph job (72 and 6 runs,
respectively, since repo creation) queued with zero steps and was cancelled after exactly 24
hours. The same pattern showed up on every other private repo checked
(HomeAutomation-Config, MediaTools, KiCadLibrary). The public ProjectTemplate repo was
unaffected, and ordinary Actions CI on the same private repos ran fine the whole time.
The cause is an account-wide setting at https://github.com/settings/security_analysis:
"Dependabot on self-hosted runners", with "Automatically enable for new repositories" also
checked. This routes Dependabot's own update jobs to a self-hosted runner pool, and no
self-hosted runner was registered anywhere on the account. GitHub deliberately never routes a
public repo through this setting, which is why ProjectTemplate kept working while every
private repo silently queued forever. The UI eventually surfaces the failure as "Self-hosted
runner unavailable" on the repo's own Dependabot page, but nothing about it appears in the
Actions API or in normal CI, so it is easy to miss.
The setting was most likely a leftover from an earlier, since-abandoned self-hosted-runner
effort on this account. Disabling the general Actions self-hosted runners did not also revert
this Dependabot-specific toggle.
What we did
Pieter disabled "Dependabot on self-hosted runners" and unchecked "Automatically enable for new
repositories" on the account settings page above. Disabling the setting does not retroactively
rerun the queued jobs, so each affected repo still needs a manual "Check for Updates" click on
its own Dependabot page.
Ask
Please consider documenting this account setting in fleet guidance (AUDIT.md, GOVERNANCE.md, or
wherever future repo stand-up/audit checks live) so a new repo under this account, or a fresh
audit pass, checks for it. A useful mechanical signal for the audit: a repo whose
dependabot-updates workflow runs are all cancelled with zero steps has this problem.
What we found
Dependabot version and security updates never ran on any private repo under this account. On
ptr727/Financial-Modeling, everydependabot-updatesandupdate-graphjob (72 and 6 runs,respectively, since repo creation) queued with zero steps and was cancelled after exactly 24
hours. The same pattern showed up on every other private repo checked
(
HomeAutomation-Config,MediaTools,KiCadLibrary). The publicProjectTemplaterepo wasunaffected, and ordinary Actions CI on the same private repos ran fine the whole time.
The cause is an account-wide setting at
https://github.com/settings/security_analysis:"Dependabot on self-hosted runners", with "Automatically enable for new repositories" also
checked. This routes Dependabot's own update jobs to a self-hosted runner pool, and no
self-hosted runner was registered anywhere on the account. GitHub deliberately never routes a
public repo through this setting, which is why
ProjectTemplatekept working while everyprivate repo silently queued forever. The UI eventually surfaces the failure as "Self-hosted
runner unavailable" on the repo's own Dependabot page, but nothing about it appears in the
Actions API or in normal CI, so it is easy to miss.
The setting was most likely a leftover from an earlier, since-abandoned self-hosted-runner
effort on this account. Disabling the general Actions self-hosted runners did not also revert
this Dependabot-specific toggle.
What we did
Pieter disabled "Dependabot on self-hosted runners" and unchecked "Automatically enable for new
repositories" on the account settings page above. Disabling the setting does not retroactively
rerun the queued jobs, so each affected repo still needs a manual "Check for Updates" click on
its own Dependabot page.
Ask
Please consider documenting this account setting in fleet guidance (AUDIT.md, GOVERNANCE.md, or
wherever future repo stand-up/audit checks live) so a new repo under this account, or a fresh
audit pass, checks for it. A useful mechanical signal for the audit: a repo whose
dependabot-updatesworkflow runs are allcancelledwith zero steps has this problem.