Discord Ticket Auto-Close Settings: Nudge, Ping, Then Close

Every ticket list ends up failing in one of two directions. Either it fills with channels nobody has touched in three weeks, so the count stops meaning anything and staff stop reading it, or it closes things too eagerly and members come back to find the conversation gone. Both are the same setting, tuned wrong in opposite directions.

What do inactivity settings do on a Discord ticket bot?

The main setting is one number: how many hours of silence a ticket is allowed. On our bot it lives on the panel, accepts anything from 1 hour to 8,760 hours (one year) or off, and is available on Premium and above. The dashboard offers 12 hours, one day, two days, three days, one week and 30 days as presets, because those cover almost everybody. Next to it sit four switches: remind members, ping staff, release unanswered claims, and close tickets waiting on staff.

Together they drive three different behaviours, in order.

Most bots stop at the third step. The interesting part is the second, because before the bot can nudge anybody it has to answer a question that a flat timer never asks.

Who owes the next reply?

The bot looks at the author of the most recent real message in the ticket and compares it to whoever opened it. That comparison decides everything that follows, and the two paths are not symmetrical on purpose.

The asymmetry is deliberate: a ticket sitting unanswered is not the member's fault, and closing it would quietly delete the evidence that your queue has a problem. So by default that direction produces a ping, one follow-up and nothing else. There is a switch to close those too, covered further down, and it is off until you go and find it.

How long should a Discord ticket stay open before it closes?

Start from the longest gap you are genuinely comfortable with, then add your weekend. Most servers land between 24 and 72 hours.

That last row is the mistake we see most often, and the cleanest fix is not a longer window. See working hours for the setting that holds staff pings and closes until you are open again, rather than stretching the window to survive the gap.

What happens before a ticket closes itself?

This is the sequence, and every step of it is a guarantee rather than a best effort.

Because the close is always planned from the moment the warning actually went out, there is no combination of settings where a ticket goes from live to closed in a single step without the member having been told.

Why did the reminder arrive earlier than I expected?

Because the reminders are timed from people, not from the window.

The bot measures how long this member took to answer earlier in the ticket, turn by turn, and leans on how fast members of your server usually answer while the ticket is still young. The reminder comes after about three times that delay, never before 30 minutes of silence and never later than a day. A member who answers within minutes is reminded sooner than one whose replies are naturally hours apart, because in the fast ticket a two hour silence means something and in the slow one it means nothing. Only the member's own replies are measured, so an AI that answers in seconds never makes a ticket look fast.

The staff ping is timed the same way, from your team: about three times how long staff on that panel usually take to answer, once the panel has eight replies to learn from, and the whole server's speed until then. Before either has been learned, it falls back to a curve scaled to your window, which is worth seeing written out:

The curve is deliberately not a flat percentage of your window. A flat ten percent would ping a 30-day ticket seven days in, which is useless, and a one hour ticket after six minutes, which is worse than useless. Scaling sub-linearly keeps the reminder a meaningful slice of a short window and a small slice of a long one, and it is clamped so it never fires sooner than half an hour or later than a day.

Does the AI keep the clock running?

While the AI is answering, every reply it sends puts the ticket back on the member's side, so your staff are not pinged about a job nobody has handed them. When the AI steps aside, because it escalated, reached its reply limit or could not answer, the ticket becomes a normal staff-owes ticket and the ping follows as usual, with a line saying so when the assistant did not answer the member's last message.

The AI's own replies count as real messages, so they reset the silence clock and flip the direction to "waiting on the member". That is the common case in practice: the AI answers in seconds, the member reads it and never comes back, and the reminder is what closes the loop.

What does not reset the clock is the bot's own housekeeping. The welcome embed, the claim notice, the reminder marker and the staff ping are all recorded as system messages, and system messages are deliberately excluded from the silence calculation. If they counted, the bot's own reminder would push the close another full window into the future and no ticket would ever close at all.

Any genuine message does reset it, from either side, and starts a fresh round of reminders. A ticket that bounces between member and staff five times gets five clean cycles, not one. The one exception is a member who ignored the last reminder: they skip straight to the closing warning until they write again.

How do you stop a specific ticket from closing?

Some tickets legitimately sit still. You are waiting on a payment provider, or a member is travelling, or the fix ships next week. Closing those is not tidying, it is losing the thread.

A paused ticket gets no reminder, no ping and no close. The reason (up to 255 characters) is posted in the channel and written to your audit log, which matters more than it sounds: the next person to open that ticket can see it was paused on purpose rather than assuming the bot is broken.

Pausing and resuming need the Close tickets permission, but anyone in the ticket can open the card, so it is the one to point a member at when they ask how long they have. The close time shows as a Discord timestamp, so they read it on their own clock, and resuming starts the quiet time again from zero.

What actually happens at the moment of close

Auto-close is not a special quiet path. It runs the same close every human close runs, which is the reason it is safe to leave on.

The transcript is the part that makes this reversible in the way that matters. The conversation still exists at its own link after the channel is gone, so a member who comes back three days later is not starting from nothing, and a closed ticket is still something you can feed back into the AI later.

Should you also close tickets your team never answered?

There is a second switch for this, off by default, and it deserves a paragraph rather than a toggle.

If you do enable it, the claimer or the staff role is still pinged first, and the ticket closes only once the window has run out and that ping has had time to be answered. The one exception is a ticket with nobody to ping, because it is neither claimed nor covered by a responsible role or because Ping staff is switched off, so it closes on the window alone. That case is worth reading as a signal in itself, because it means tickets are arriving somewhere nobody is assigned.

What about web chats from your website?

The website widget runs the same engine with its own window and switches, and only the delivery differs. A visitor who signed in with Discord gets the same reminder by direct message, with a button back to the chat, and every visitor sees the closing warning in the chat itself. A visitor whose chat does close gets a line explaining why before it flips to closed. Staff pings go to the chat's thread in your server, so a web chat that never got a thread is never pinged.

When auto-close is the wrong setting

Two honest limits worth stating plainly. The window is per panel, so a server that needs a fast window on general questions and a slow one on refunds needs two panels, not one setting. And on a panel with working hours, staff pings and closes wait for you to be open, which is a feature rather than a bug, but it does mean the effective window on a server that closes at weekends is longer than the number in the box. Member reminders are not held back.

Setting it up without breaking anything

The last one is the only real test. If members are reopening tickets that closed on them, your window is too short or your nudge is not landing. If the list still fills with dead channels, it is too long. Nobody gets this right from the first guess, and the number is one field.

The setting behind the setting

Auto-close is a housekeeping tool. It makes a ticket list readable again, and it is worth every minute it takes to configure, but it does not reduce the number of tickets you get and it does not answer any of them.

The things that do are elsewhere. An AI first pass resolves the ticket before silence is even relevant, and across this bot's lifetime that has been roughly half of more than 180,000 tickets. Asking the right questions at the moment a ticket opens means fewer rounds of back and forth for the timers to sit through. Answering repeat questions in public means those tickets never exist to go stale.

Configure the window, then go and work on the reason your tickets go quiet.