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?

You set 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), and is available on Premium and above. The dashboard offers one day, two days, three days, one week and one month as presets, because those cover almost everybody.

That single number then drives 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 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 suspends every one of these timers while you are closed, rather than stretching them 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 check runs every 15 minutes and the grace floor is also 15 minutes, the nudge always lands in an earlier pass than the close. 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 nudge arrive earlier than I expected?

Because the close deadline is fixed and the warnings before it are not.

The bot looks at the recent messages in that specific ticket and measures the median gap between them. A conversation where both sides were replying within minutes gets its nudge sooner than one where replies were naturally hours apart, because in the fast ticket a two hour silence means something and in the slow one it means nothing. The threshold is bounded by your window at both ends, so it can never drift past the close.

The staff ping does the same thing, scaled to your window in a way that 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 actively working a ticket, your staff are not pinged for being slow. That would be a notification about a job nobody has been handed yet. Once it hands off to a human, the ticket becomes a normal staff-owes ticket and the timers apply as usual.

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 nudge is what closes the loop a day later.

What does not reset the clock is the bot's own housekeeping. The welcome embed, the claim notice, the nudge 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 nudge 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 doing so re-arms both warnings. A ticket that bounces between member and staff five times gets five clean cycles, not one.

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 is dropped from the sweep completely, so there is no nudge, 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.

Pause is staff-only, and status is the one to reach for when a member asks how long they have. It shows the projected close time as a Discord timestamp, so they read it on their own clock.

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 sequence is the same as the member direction: the claimer or the staff role is pinged first, gets the same grace period, and only then does the ticket close. The one exception is a ticket that is neither claimed nor covered by a responsible role, where there is nobody to ping, 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 decision logic with its own window, and only the delivery differs. There is no Discord account to direct message, so the nudge arrives as a message in the chat itself, and a visitor whose chat does close gets a line explaining why before it flips to closed. If a mirror thread exists in your server, your staff get a note there too.

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 the timers are suspended entirely by working hours, 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.

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.