Discord Ticket Search: How to Find an Old Ticket

Six months in, a server has a few thousand ticket records and no memory of any of them. Somebody asks whether that refund was ever processed, and the answer depends entirely on what your staff typed into a box on the way out.

How do you search tickets in a Discord server?

Run /ticket search anywhere in the server. Not inside a ticket, and not in a direct message: it is scoped to the server it is run in, and it reads every ticket that server has ever had.

The reply is private to you. Ten results a page, newest first, each one a line carrying the channel name, status, priority, panel, opener and how long ago it opened, with a dropdown to open any of them in full. Web chats and tickets from a connected third-party bot are marked so you can tell at a glance why they have no channel to jump into, and an anonymous web visitor with no Discord account reads as "Website visitor" rather than as a broken mention.

That last line is worth more than it looks. The view re-queries live data each time you turn a page, so the permission check cannot be a one-off from the moment you typed the command. A staff member who loses their role mid-session loses the results with it.

The gate being the base support permission rather than a reporting one is a deliberate split. Finding a ticket is part of doing the job. /ticket stats, which aggregates rather than lists, is the one behind the See stats permission and behind Premium for its longer windows.

What can you actually filter by?

Eleven options, and they combine. Everything is optional except the window, which has a default.

Two of those are worded carefully on purpose. Closed without staff is not "the AI solved it": the underlying condition is that the ticket closed with the AI having replied and no escalation recorded, and a staff member can take a ticket over without that escalation ever firing. The filter reports what the query does rather than the flattering version of it.

Panel is capped by your plan. If a downgrade has put a panel out of reach, it is neither offered in the autocomplete nor accepted if you type it, and the refusal is identical to the one for a panel that never existed. Its tickets still appear in unfiltered results, because history is never hidden, only the filter is.

Why can you not search what people said?

This is the question the filter list raises and it has a real answer rather than a roadmap answer.

When a ticket closes, the bot does five things in one transaction: it works out the timing bounds of the conversation, flips the ticket to closed, writes one contribution row per staff member who took part, builds the transcript, and then deletes the ticket's message rows.

The conversation is not lost. It moves into the transcript, a stored document served at its own link, and the per-staff credit moves into a contributions table that keeps it permanently. What goes away is the searchable copy, the heavy message text a query would have to scan. So a closed ticket has no message rows left to search, and an open one, which still has them, has no filter that reads them either.

Two consequences follow. Storage stays flat as a server grows, which is part of why this is free rather than metered. And the conversation lives under one retention clock instead of two: ninety days on Free, two years on the paid plans, after which the transcript stops opening. The ticket record, and everything you can filter on above, stays.

What makes a ticket findable a year later

The close reason, and nothing else. Closing a ticket well covers what belongs in that box and why it travels further than any other text in the product. What that article does not cover is how the matching behaves, which changes what a useful reason looks like.

It is a case-insensitive substring match on one field. refund finds "Refunded on order 4471". There are no word boundaries, so it also finds "non-refundable", and no way to require two words at once or exclude one. The field caps at 255 characters. Write the noun a future search would use, put it early, and resist writing a sentence.

Automatic closes are searchable too, because the bot stores a stable code rather than a sentence and then translates it for display. Search the code, not the words you see in your log channel.

Searching inactivity finds every ticket in the first row, because it is a substring of the stored code. Searching for the phrase you read in the log post will not: the display says "User left the server" while the stored value is user_left_server, so one word is a safer search than a sentence.

Discord or the dashboard?

Both search the same close reason field. What differs is who can reach them and what else they offer.

The export has no equivalent in Discord and it is the closest thing to searching a conversation. Filter the list down, select the tickets, export them with the conversations included, up to a hundred at a time, then search the file. A metadata-only export, the spreadsheet of who opened what and when, goes up to a thousand rows. That is a workaround rather than a feature, and it is worth calling one.

Where ticket search falls short

One rough edge is worth naming plainly, because it looks like a broken product and is not. A ticket whose transcript has aged out still shows a transcript button on the staff side, and the link then reports that the transcript is gone. The member-facing /mytickets view checks the retention clock first and says "no longer available" instead. The staff view does not run that check yet, and we have reported it internally. Until it changes, treat that button on an old ticket as a maybe rather than a promise.

Making your server searchable

None of it costs anything. The searchable half of a ticket is written by a human at the moment they are least interested in writing it, which is why the format is worth agreeing once instead of hoping.