Close Stale Issues Bot

Overview

FlowLibs - Close Stale Issues Bot runs on a weekly recurrence and prunes the backlog in a single GitHub repository. Every Monday morning it pulls all open issues carrying a configurable "waiting-for-response" label, then for each issue whose updated_at is older than a configurable day threshold it posts a courtesy comment via the GitHub REST API and closes the issue with state_reason = not_planned. The result: your triage queue stops drifting, issues awaiting info get a gentle nudge-and-close instead of lingering forever, and the label drives everything — no code changes to tune behavior.

## When To Use Use this flow when you have a single GitHub repository where issues frequently stall waiting for additional information from the reporter. The label-driven model means you (or your team) simply tag an issue waiting-for-response, and from that moment on the flow controls its lifecycle. Drop the label, and the flow will ignore it. Pair this with an issue-template rule ("requires reproduction steps") and the stale-issue workflow becomes fully self-service.

Use Case

Use this flow when you have a single GitHub repository where issues frequently stall waiting for additional information from the reporter. The label-driven model means you (or your team) simply tag an issue waiting-for-response, and from that moment on the flow controls its lifecycle. Drop the label, and the flow will ignore it. Pair this with an issue-template rule ("requires reproduction steps") and the stale-issue workflow becomes fully self-service.

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Tune inactivity window via env var

Update flowlibs_StaleIssueDaysThreshold to change how long an issue can sit before being closed — no flow edit required.

Track a different label taxonomy

Update flowlibs_StaleIssueLabel to point at a different label (e.g. needs-info, pending-author). The flow logic stays put.

Rewrite the closing comment

Edit flowlibs_StaleIssueClosingComment to match your team's tone. The exact string is posted verbatim on each closed issue.

Target a second repository

Clone the solution, change flowlibs_GitHubRepository, and deploy side-by-side. Each instance can have its own label/threshold.

Change cadence

Edit the Recurrence trigger's frequency/interval to scan daily, twice a week, monthly, etc.

Widen scan beyond 100 issues per run

Replace the single Get Open Stale Labeled Issues call with a paginated loop — add an Until around the GitHub list action keyed off page number until the response body length is < 100.

Drop the HTTP fallback when GitHub adds native comment op

If the GitHub connector ever ships a native create issue comment operation, the built-in HTTP action is the only piece that needs refactoring — the rest stays put.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

@{addDays(utcNow(), mul(-1, int(variables('varStaleIssueDaysThreshold'))))}

@less(items('For_Each_Open_Issue')?['updated_at'], variables('varStaleCutoffUtc'))

Authorization: token @{variables('varGitHubPAT')}

{ "state": "closed", "state_reason": "not_planned" }