Why Do Discord Forum Posts Get Buried Once New Threads Start?
An old forum-channel post disappears once newer posts push it down the list because Discord forum channels sort posts by activity, not by importance, and a brand-new post counts as recent activity the moment it's created. Your feature request doesn't have to go quiet for this to happen. Ten other people just have to start ten other threads while yours sits with zero replies, and it drops ten spots without a single thing happening to it.
This is a different failure than a thread going stale. Discord's own Forum Channels FAQ documents a separate, later stage: once a post has been inactive for a set stretch (1 hour, 24 hours, 3 days by default, or 1 week, moderator's choice), it moves wholesale into an "Older Posts" section. That's the archive. What happens before the archive, while your post is still technically active and still on the board, is simpler and gets talked about less. It's just not near the top anymore, and nobody scrolls a forum channel the way they'd scroll a Slack channel looking for something specific.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe sort order is doing exactly what it's built to do
Discord's developer documentation for the channel resource specifies two sort modes a forum channel can use, set on a default_sort_order field: LATEST_ACTIVITY, described as sorting "forum posts by activity," and CREATION_DATE, which sorts "by creation time (from most recent to oldest)." A server admin can set either one; until they do, the field is null.
Neither mode helps an old, quiet post. Under LATEST_ACTIVITY, a post with a reply an hour ago outranks a post with a reply a week ago, so a thread that gets even one comment can hold its spot near the top, but a thread nobody has touched since it was posted has nothing pushing it back up as new threads accumulate above it. Under CREATION_DATE, it's blunter still. The list is ordered by when each post was made, full stop, so a post from three weeks ago is mathematically behind every post made since, whether or not anyone ever replied to any of them. Either way, a post with zero comments and a post that got fixed and forgotten produce the same outcome, sinking at the same rate.
Layout compounds it. Forum channels can display as a list or, per the same developer docs, as a GALLERY_VIEW, described as "a collection of tiles," which shows fewer posts per screen than a plain list does. A gallery view with six visible tiles buries a post after the sixth new thread instead of the twentieth.
A support forum with more requests than screen space
Marrow Editor is a three-person startup building a Markdown-native writing tool for technical documentation teams, and its entire Discord community falls to Odessa Fain. The company's Discord runs on whatever settings Discord shipped with, since nobody had gone in to change them. The #feature-requests channel has about 900 members and displays as a plain list, not the tile-based gallery some servers use.
In early September, a user posted:
community member: any chance of a "compare two versions" diff view? we paste old and new drafts into a separate diff tool right now, would be nice to just click a button in Marrow
Two people reacted with a thumbs-up. Nobody replied. Over the following ten days, fourteen other posts went up in the same channel: bug reports, a request for dark-mode syntax highlighting, someone asking about the CLI, each one landing above the diff-view request the moment it was created, comments or not.
Odessa's weekly sweep of the forum means reading whatever's visible on the first two screens of the list, because that's what a sweep is for a channel with this much traffic. The diff-view post was gone from that view by the second week. It resurfaced only because a second user, in late September, opened a support ticket with almost the same wording:
support ticket: feature idea, side-by-side diff for two draft versions. we're manually diffing outside your app which defeats the point of writing everything in Marrow.
Odessa searched the Discord forum for "diff" to check whether this had come up before, found the September post, and realized it had been sitting one page down from visible the entire time. Two people had independently wanted the same feature three weeks apart, and the only reason the team could tell was that Odessa happened to search the right word on the right day.
What actually helps inside Discord
None of this makes forum channels unworkable, and a few settings changes cut down how often a post like the diff-view request goes unseen.
- Set
CREATION_DATEsort if new requests matter more than active arguments. It won't stop new posts from ranking above old ones, but it makes the ranking predictable and free of the illusion that a quiet post with old activity is somehow still "recent." - Switch to
LIST_VIEWover gallery, if the channel isn't currently using it. More posts visible per screen means fewer requests fall past the fold before someone scrolls. - Use the one pinned-post slot deliberately. Forum channels support exactly one pin at a time, per Discord's FAQ, so it's only useful as a rotating spot for whatever request the team most wants to keep visible this week, not a real archive.
- React or reply to every new post within a day, even just "logged, thanks." Under activity-sort, a reply is the only thing that keeps a quiet request from sinking purely on the calendar.
These buy time. None of them change the fact that rank in a list, however it's computed, is a proxy for recency and reply count, never for how many people actually want the thing.
How much volume breaks the sweep
A weekly read-through of the first two screens holds up while a forum channel produces fewer new posts per week than one person can hold in their head. It stops holding up the moment volume crosses that, because the sweep, by construction, only sees what's currently visible, and "currently visible" is defined by everyone else's posting pace, not by what actually matters. A commenter on Hacker News argued that Discord was built for "deep users and groups of friends who had lots of preexisting context" rather than people looking something up cold. A support-facing forum has to work for someone with zero memory of what's been posted before, and a sort order that rewards recent activity does the opposite of that.
That's the point where reading every post the moment it lands, independent of where it ends up ranked an hour later, stops being optional. Modem does exactly that. Modem's Discord integration reads every post in the channels you connect, the moment they're posted, and rolls matching requests into one counted topic with every requester attached, regardless of how many newer threads eventually bury the original post in Discord's own list. Odessa's diff-view request and the near-identical support ticket three weeks later would have landed in the same topic automatically, both people counted, instead of surfacing only because someone happened to search "diff" on the right afternoon. We build Modem, so weigh this recommendation accordingly. A channel small enough for one person to read every new post before the next batch buries it doesn't need this yet, and the settings above are a reasonable place to stop.
For the wider setup of a support-facing Discord server, including channel structure and pinned templates, see how to get product feedback from a Discord community. If requests specifically need to land in GitHub rather than staying in Discord, the tools built to turn Discord messages into GitHub issues compares the options for that hop.
Start with sort order and layout
Open the forum channel's settings and look at the sort order and layout. If it's still whatever Discord defaulted to, decide on purpose whether new posts or active arguments should win the top of the list, and switch to LIST_VIEW if the channel is on gallery. That alone won't stop posts from sinking, but it stops the sinking from being an accident nobody chose.
