Discord Ticket Bot Downtime: What Happens to Open Tickets

Every ticket bot goes down at some point. Ours has, and the last ninety days of it are published. The question worth answering is not whether a bot has bad days, because they all do. It is what a bad day actually costs you, and that depends entirely on where the bot keeps things while it is running.

The short version is that it keeps almost nothing. The channel belongs to Discord, every deadline is written down with a time on it, and every button carries enough information to answer a click on a message the bot has never seen. An outage is therefore a gap rather than an event: it leaves nothing behind except the minutes themselves.

What happens to an open ticket when the bot goes offline?

Short answer: the ticket carries on and the bot's contributions stop. Members and staff can still read the channel, type in it, upload files, mention each other and do everything Discord does on its own. What they cannot do is anything that needs the bot to answer, which is the buttons, the slash commands and the AI.

The button row is worth understanding because it is the part members see. Discord gives a bot roughly three seconds to acknowledge a click. If nothing answers, Discord tells the member the interaction failed and that is the end of it: no half-created ticket, no duplicate, nothing queued up to fire later. Pressing the same button again once the bot is back does exactly what it would have done the first time.

Where the state actually lives

The reason an outage is cheap is structural, and it is the thing to check about any Discord ticket bot you are considering, not just this one. Ask where each piece of a live ticket is stored, and whether that place survives the bot being stopped.

That last one is the least obvious and it does the most work. A button posted three days ago sits on a message the bot has no memory of after a restart. It still works because the ticket it belongs to is written into the button, so the click arrives already saying which ticket it is about. The same applies to a direct message, which is why a close request can sit unanswered for seven days, and a reminder DM for longer than that, and still do the right thing when somebody finally presses it.

Deadlines work the same way for the same reason. A ticket that should be reminded at half past two has a row saying so. If the bot is not running at half past two, the row does not evaporate, it simply becomes overdue, and overdue rows are the first ones picked up when the bot returns.

What you do lose: the minutes it was not listening

Messages are recorded as they arrive. There is no catch-up pass that reads the channel afterwards, and that is a deliberate choice rather than an oversight, because a bot that re-reads history to fill gaps also re-reads messages that were deliberately deleted.

In practice this matters for one thing: a ticket closed shortly after an outage may have an archive that is missing its middle. If a ticket from that window is one you expect to need later, copy the conversation out of the channel before the channel is deleted. How ticket transcripts work covers what the archive normally holds and how long it is kept.

It is worth saying plainly because most of this article is reassuring and this part is not. An outage does not lose your tickets. It can lose your record of a few minutes inside one.

What happens to reminders and auto-close during an outage

This is where a naive design does real damage. If deadlines are just times, a bot that was off for six hours comes back to a pile of tickets whose close time passed hours ago, and closes all of them at once, silently, on people who were never warned.

That cannot happen here, because closing for silence has a precondition rather than a time.

The close is only permitted once the warning has actually been sent, and the wait before the close is measured from the moment that warning really went out rather than from when it was supposed to. So a ticket whose warning and close both came due during the outage does not get closed on the way back. It gets its warning, and then the full warning period on top of it.

There is a second piece of politeness in the same place. When both the early nudge and the closing warning became due while the bot was away, the member gets one message rather than two arriving together, because two identical-looking prompts in the same second read as a broken bot rather than a considerate one. Auto-close settings explains the normal timing, and the direct messages a ticket bot sends covers which of these arrive as a DM.

The catch-up itself is paced. A backlog is worked through oldest first with a cap on how much is done each minute, so a busy server does not get an hour of accumulated notifications delivered as one burst.

When the AI is the part that is down

The AI can fail without the bot failing, and the two are worth telling apart. A member opens a ticket, staff can claim it and reply, the transcript records everything, and the only missing piece is the automatic first answer.

When a turn cannot reach the AI, the ticket says so once and stays open. Three details in that sentence were chosen deliberately:

• The AI is not turned off by it. A temporary fault used to switch the AI off on every ticket it touched, permanently, until a staff member turned it back on in each one by hand. That was the wrong shape for something that fixes itself in minutes, so a fault now leaves the switch alone and the AI answers again on the member's next message.
• The notice is said once. A member typing three messages into an unreachable AI gets one explanation, not three, and it does not repeat for half an hour.
• A ticket the AI never spoke in says nothing. Telling somebody that an assistant they never met is unavailable explains nothing to them, so those tickets open as ordinary staff tickets with no apology attached.

The notice is also recorded in the transcript alongside everything else, which is the small thing that stops a reader six months later from seeing the AI go quiet for no visible reason. What an AI support bot will not do covers the other reasons it stops, most of which are decisions rather than faults.

How to tell whether it is the bot, Discord, or your server

Start with the status page. It is served by the website, which runs separately from the bot, so it keeps answering when the bot does not.

Two honest limits on that page. A check every sixty seconds cannot see a blip that lasted twenty seconds, so short faults you noticed may not appear. And incidents are written up by a person, so the history is as good as our willingness to write down our own bad days, which is why the empty stretches on it are not evidence of anything on their own.

If the status page is green and your server is still quiet, the usual causes are Discord itself, which publishes its own status page, or a permission change on your side. A bot that answers in one channel and not another is almost never an outage. Ticket bot permissions is the faster thing to check first.

Where a hosted ticket bot is the wrong choice

We are hosted only. Our uptime is our problem to fix and yours to live with, and that is a real trade rather than a detail. If you need to be the one who decides when it restarts, open source ticket bots is the honest place to look, and the cost moves from a subscription to your own time and your own bad nights.

The middle ground most servers land on is neither of those. Keep the bot hosted, and make sure the one thing you would genuinely miss, which is usually the written record, is not the thing you are depending on the bot to have captured in the exact minute it was down.