Why Does Discord Search Fail to Find Old Feature Requests?
A feature request posted in your Discord server six months ago isn't gone. It's still sitting in the channel, unedited, exactly where it was typed. Search still can't find it, for two separate reasons: it matches the words you type against the words that were typed originally, with no idea that "flash over USB-C" and "skip the serial dongle" mean the same thing, and Discord's own developer documentation admits its search index quietly returns fewer results for messages nobody has touched in a long time.
Neither reason is about retention. Nothing in Discord's search documentation ties these gaps to deleted messages: the behavior it describes, fewer results for content nobody has touched in a while, is about how the index treats old activity, not about anything getting purged, and Discord doesn't cap free-tier history the way some chat tools do. The request you're hunting for is almost certainly still sitting in the channel. The problem is entirely about what search can and will surface, not what got deleted.
What Discord's own docs say is happening
Discord documents the mechanics behind its guild message search in its developer reference, and two details there explain most of what users run into.
First, search is a keyword match with a small set of structural filters, not a meaning match. The documented parameters are things like content (the text to match, capped at 1,024 characters), has (attachment types: image, video, file, link, embed, sticker, poll), channel_id, author_id, mentions, and pinned, plus a sort_by of timestamp or relevance. None of those filters know that two messages are about the same feature if the words don't overlap. A request phrased "any chance of USB-C flashing" and a later search for "serial port" will never connect, because nothing in the system is comparing meaning, only strings.
Second, and less obvious: Discord's docs state plainly that "search may return slightly fewer results than the limit specified when messages have not been accessed for a long time," due to what the docs call speed optimizations, and add that clients shouldn't rely on the size of the results array for pagination. In plain terms, the index deprioritizes content that's gone cold. A feature request from a busy launch week that nobody reopened since is exactly the kind of message this note describes. Search isn't guaranteed to surface all of it, even with the right keyword.
The same reference also caps how far back you can dig by hand. Results return in pages of up to 25, and the maximum offset is 9,975, which puts a hard ceiling on how many pages of search results are even reachable before Discord's own API stops letting you page further. And if the channel's content hasn't been indexed yet, the endpoint returns a 202 response instead of results, with a retry_after value telling you when to try again. None of this is a bug. It's what a keyword index with a freshness bias looks like when you ask it to reach back through history.
“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 NotionA support call two days before the roadmap review
Elena Bosch handles developer relations for a five-person team that sells a robotics dev kit to hobbyists and ships firmware updates through a public Discord server with about 4,000 members. Two days before Q4 planning, an engineer asks her whether anyone actually asked for overnight firmware pushes, or whether it just sounds familiar because two people mentioned it in a meeting once.
Elena searches the #firmware-feedback channel for "overnight." Nothing. She tries "schedule." Two recent hits, both about a livestream schedule change, nothing from earlier in the year.
The message she's actually looking for, from January, reads:
grim_axel: any chance you could push updates at like 2am instead of whenever, keeps interrupting me mid-test and I have to redo the whole run
No one wrote "overnight." No one wrote "schedule." grim_axel wrote it the way a person types when they're annoyed mid-task, and that phrasing never resurfaces in a keyword search for the feature's proper name. Elena only finds it by scrolling back through January by hand, roughly guessing which week based on when a firmware update went out that might have prompted the comment.
Once she has the right words, she tests them: a search for "overnight" sorted by relevance still puts grim_axel's message on the second page, behind three messages from that same morning about an unrelated server outage. The January message hasn't been touched since the day it was posted, so the index treats it exactly the way Discord's own docs describe: deprioritized for staleness, not absent, and still hard to find even once you know what to search for.
It's a real request, and it's the third time this shape of request has come up in that channel by her count, but she only has three because she happened to remember two of them and manually confirmed the third. She has no way to know if there's a fourth she's forgotten, sitting in a February or May she didn't think to scroll through.
What actually reduces this, inside Discord
None of this makes Discord unusable for a small community, and a few habits cut down how often it happens:
- Pin confirmed requests as you find them. The
pinnedfilter is one of the few search parameters that isn't a keyword match, so a pinned list of requests is reliably searchable regardless of how the original message was phrased. - Route feedback into one narrow channel. A dedicated
#feature-requestschannel, kept separate from general chat, meanschannel_idscoping alone gets you most of the way to a clean list, and it's less likely to fall into the "not accessed in a long time" bucket the docs warn about, since a smaller, purpose-built channel gets revisited more often. - Log the noun, not the verb someone used to ask for it. grim_axel's message would surface for a search on "2am" or "overnight" far more reliably than for "push" or "interrupting." Search for the part of speech that doesn't change between phrasings.
- Restate requests back into the channel in consistent language. A moderator reply like "logging this as: overnight firmware pushes" gives the next search a fixed string to match, even if the original ask never used those words.
These habits raise the odds that a given search hits. None of them fix the two underlying issues. The index still favors recently touched content over old, and nothing is deciding at the moment a message is posted whether it's a feature request worth tracking at all; that judgment still depends on a human noticing and, ideally, pinning.
Past a certain size, the medium itself is the limit
The habits above hold up for a server with one feedback channel and a moderator who reads most of it. They stop holding up once a community crosses a few thousand active members or spreads feedback across a dozen channels, because pinning is a discipline that degrades under volume the same way any manual process does, and nobody's memory of "roughly what was said, roughly when" scales past the point where they personally read every message.
This isn't a complaint specific to how Discord built its search. A commenter on Hacker News made the same point about chat tools generally: "It's a chat app, not a good medium to expose any information for people to be able to check when needed." The keyword matching and the freshness bias are the specific mechanics; the underlying issue is that a running stream of messages was never built to double as a lookup table, no matter how good the search on top of it gets.
That's the point where a layer that reads Discord as it happens, rather than being searched after the fact, earns its cost. Modem's Discord integration reads the channels you connect it to, classifies feedback the moment it's posted, and merges different phrasings of the same request, "push updates at 2am" and "overnight firmware pushes," into one counted topic tied to the person who asked, regardless of what words a future search happens to use. Modem does the same across Slack, support tools, and issue trackers, so a request doesn't depend on any one channel's search working well.
That's also, plainly, the product we sell, so read the sizing claim above with that in mind. If your server has one feedback channel, a moderator who actually reads it, and a member count you can still hold in your head, the pin-and-restate habits are probably all you need. The math changes once that discipline has to hold across multiple channels or a community too large for one person to track from memory, which is the point where paying for something that doesn't forget starts costing less than the time spent re-deriving what people already asked for.
The same "search finds words, not requests" problem shows up in other chat tools for the same reason. See why Slack search struggles to surface old feature requests for the equivalent breakdown there. For teams evaluating Discord-specific capture tools more broadly, the best Discord feedback tools for devtools companies compares six options on how they capture rather than how they retrieve.
Three changes, plus one recurring check
Create a #feature-requests channel if you don't have one, pin every confirmed request the moment it's identified, and have whoever moderates restate each one in consistent language as a reply. That alone turns the next "did anyone actually ask for this" question into a pinned-messages scroll instead of an afternoon of guessing which month to search.
Then add one recurring habit the bullets above don't cover: once a quarter, search the channel with sort_by=relevance for your two or three most common request themes and see what surfaces that isn't already pinned. That's the cheapest way to catch the requests that slipped past staleness deprioritization before a roadmap review forces the question, and it won't catch everything, but it catches more than waiting for someone to ask.
