GitHub repositories can develop a backlog layer that is difficult to intuit from an issue list alone.
An issue can look stale for very different reasons, such as a fix that landed in an unlinked neighboring pull request or a feature request that was replaced by a newer thread. Months later, those cases are still open, inactive, and unable to be triaged without rereading the conversation.
Classic stale bots don't do that rereading. They run on date arithmetic. Sixty days without activity? Label it stale. Seven more days without a comment? Close it. Doesn't matter if it's an abandoned support request, a valid bug waiting on a maintainer, or a feature with 800 upvotes that just went quiet. They can't tell the difference between "nobody cares" and "everyone is waiting." Someone who spent an hour filing a careful bug report gets the same treatment. A lot of them don't file again.
Trust is the whole product here because closing the wrong issue is expensive.
Today, we are open sourcing better-stale-bot, an AI stale bot for GitHub Issues that reads your threads before taking action.
It finds inactive issues, summarizes what happened, classifies whether the issue looks resolved or still open, leaves a contextual stale comment, and closes the issue only after the configured grace period. If a non-bot user replies, it removes the Stale label instead of continuing toward closure.
better-stale-bot is an open source alternative to Dosu's internal stale bot for teams that want stale issue automation with context, auditability, and guardrails.
Note: The demo screenshots use small
days-before-staleanddays-before-closevalues to test. The shipped defaults are 60 days before labeling and 7 days before closing. We recommend you set your own policy before turning it on.
Why We Built It
Dosu has had a smart stale bot inside the hosted product for a long time. It was one of the earliest pieces of issue automation we shipped. Dosu could evaluate aging issues, summarize the thread, mark them stale, and close them when there was no further activity.
That feature worked because it sat on top of Dosu's hosted infrastructure. We handled GitHub app auth, queues, model routing, retries, Slack logging, per-repo configuration, maintainer tagging, and the little edge cases around users replying after an issue was marked stale.
We believe maintainers should be able to run this kind of automation directly in their repo, inspect the policy in plain text, and change the behavior without adopting a hosted service. So we pulled the stale-bot idea out of Dosu, rewrote it as a standalone workflow, and made it open source.
We are deprecating the hosted stale bot in the Dosu app on August 1, 2026. If you currently use Dosu's stale bot, better-stale-bot is the migration path. Same core idea, less hosted machinery, and more control in your repository.
Stale issue automation is the final pass in the broader GitHub issue management loop we have written about before, alongside automating GitHub issue triage, building a durable open source labeling scheme, and using auto-labeling to keep backlogs organized.
How better-stale-bot Works
better-stale-bot is built with GitHub Agentic Workflows. Instead of writing a custom GitHub App or hosting a service, you write the automation as a Markdown file in .github/workflows/.
The YAML frontmatter configures the schedule, permissions, model engine, GitHub tools, and safe output limits. The body is a plain-language policy for the agent. Running gh aw compile turns that Markdown file into a .lock.yml workflow that GitHub Actions can execute.
The whole setup stays intentionally small.
- The policy is readable Markdown.
- The compiled workflow runs inside GitHub Actions.
- The model can use GitHub tools, but only within the permissions you grant.
- Writes are capped by
safe-outputs, with separate limits for comments, labels, label removals, closes, and no-op reports. - You can use Claude, Copilot, or Codex by changing the engine and setting the matching secret.
The template defaults to Claude Haiku because it is a good cost-to-quality fit for this job. If your repo needs a different model, change the engine field and recompile.
How It Compares to actions/stale
actions/stale is a good tool when your policy is purely time-based. better-stale-bot is for teams that want an AI GitHub stale bot that reads context before acting.
actions/stale | better-stale-bot | |
|---|---|---|
| Decision logic | Timer-based | The agent reads and summarizes the thread |
| Comment body | Static template | Issue-specific summary and next steps |
| Language | Whatever template you write | Language of the issue title |
| Processing order | Time-based | Low-engagement issues first |
| Resolved detection | None | Classifies resolved vs. unresolved |
| Re-engagement | Configurable activity rules | Removes Stale on qualifying non-bot activity |
| Write limits | Workflow configuration | Agentic Workflow safe outputs |
| Audit trail | GitHub Actions logs | GitHub Actions logs plus agent reasoning |
The difference is not "AI for the sake of AI." The difference is that stale issue management is a reading task before it is a labeling task.
Try It on Your Repo
Issue triage is one of those jobs teams keep doing manually because the automation has historically been too blunt. We think the right version is smaller, more inspectable, and more context-aware.
That is the point of better-stale-bot, a workflow that reads before it closes and keeps the stale issue policy visible in your repo.
Check out the repo at dosu-ai/better-stale-bot on GitHub
If something misbehaves, open an issue or chat with us on Discord. If you go quiet, the bot might stale-label it.