After the Deferral — Discord's 15-Minute Interaction Window

Everyone learns the three-second rule — acknowledge an interaction fast or it fails. Fewer people learn what the acknowledgement actually buys, and that's where the surprises live. Interaction tokens are valid for 15 minutes, so every followup and edit has to happen inside that window. There are two kinds of deferral, and for buttons the difference is whether your user stares at a loading spinner they didn't need. And on a container platform there's a third catch nobody documents: if your app restarts between the deferral and the followup, the followup never arrives — leaving a spinner that spins until the user gives up.

What the token gives you#

Per Discord's documentation, "you must send an initial response within 3 seconds of receiving the event", and "interaction tokens are valid for 15 minutes" (Discord docs).

So the shape is: acknowledge in three seconds, then you have a quarter of an hour to edit that response or send followups. For most work that's generous. For a few cases it isn't, and those are worth designing for rather than discovering.

Two deferrals, and buttons want the quiet one#

This is the detail that separates a polished bot from an irritating one.

• DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE (type 5) — "ACK an interaction and edit a response later, the user sees a loading state".
• DEFERRED_UPDATE_MESSAGE (type 6) — "For components, ACK an interaction and edit the original message later; the user does not see a loading state".

The distinction is the visible spinner. If a button does something quick and quiet — toggling a setting, flipping a page, marking something done — type 6 acknowledges it without telling the user to wait for something that's already finished. If a button starts real work, type 5 is honest: the spinner is information.

Getting this backwards is a small thing that reads as sloppiness. A "next page" button showing a loading state for 80 milliseconds looks broken; a button that silently starts a 30-second job looks ignored.

Fifteen minutes is a real constraint for AI bots#

For a slash command that queries a database, the window is irrelevant. For anything model-backed, it's a design input.

A long chain of tool calls, a document being summarised, a task with retries and backoff — these can genuinely approach or exceed fifteen minutes. When the token expires, you can no longer edit the original response, and the user is left with whatever you last showed them.

Two honest patterns:

• Post a new message instead of editing. Store the channel ID up front, and when the work finishes, send a fresh message mentioning the user. It loses the tidy in-place update but it always works.
• Update before the window closes. If the job might run long, edit the response at, say, twelve minutes with "still working, I'll post the result here" — then follow up with a normal message. The user gets a definite state rather than an ambiguous one.

Either way, cap the work so "might take twenty minutes" isn't an open-ended promise.

The restart problem nobody mentions#

Here's the container-specific part.

Deferring is a promise to come back. That promise lives in your process — the pending task, the token, the plan to edit a message. Your container is replaced on every deploy and every configuration change, and roughly a second after the stop signal it's gone.

So a deploy that lands between "user clicked" and "bot replied" leaves an interaction that will never be answered. The user sees a permanent loading state, because from Discord's side you simply never came back.

Three ways to handle it, in order of effort:

• Keep the deferred work short. If a handler finishes in a couple of seconds, the window where a restart can hurt is tiny. This alone covers most bots.
• Deploy when it's quiet. Deploys are quick, and the exposure is only the in-flight interactions.
• Persist the intent. For work that genuinely takes minutes, write the task to a volume before deferring — including the token and channel — and on startup, finish or abandon anything outstanding. Since tokens expire in fifteen minutes, "abandon and post a fresh message" is often the right recovery.

The general principle is the same one that applies to everything here: in-memory state doesn't survive a restart, and interactions are state with a deadline attached.

Old buttons still work#

A common confusion worth clearing up: the fifteen-minute limit applies to the interaction, not to the message.

A button on a message from last week is still clickable, and clicking it creates a new interaction with a new token and a fresh three-second deadline. What you can't do is use last week's token to edit anything today.

Which means your handler must be able to reconstruct context from the interaction itself — the custom ID, the message, the user — rather than from anything you were holding in memory when you first sent it. A bot that only works if it remembers sending the button is a bot that breaks on every deploy.

FAQ#

How long do I have to respond to a Discord interaction?#

Three seconds for the initial acknowledgement. After that, the token is valid for 15 minutes for edits and followups.

Which deferral type should a button use?#

DEFERRED_UPDATE_MESSAGE for quick, quiet updates — the user sees no loading state. Use the loading variant when there's real work to wait for.

What happens if my task takes longer than 15 minutes?#

The token expires and you can't edit the response. Post a new message in the channel instead, and tell the user before the window closes.

Why does my button spin forever?#

Either you never acknowledged the interaction, or your app restarted before sending the followup. Deferral is a promise your process has to keep.

Do buttons on old messages still work?#

Yes. Each click is a new interaction with a new token. Just don't rely on state you were holding when the message was sent.

How do I make this survive a deploy?#

Keep deferred work short, or persist the pending task and reconcile on startup. Fifteen-minute tokens mean recovery often just means posting a fresh message.

Wrapping up#

The three-second rule gets all the attention because it fails loudly and immediately. The fifteen-minute window fails quietly and later — a spinner nobody watches, a result that never arrives — which makes it easier to ship and harder to notice. Pick the right deferral so users aren't told to wait for nothing, plan for work that outlives the token, and remember that a deferral is a promise made by a process that gets replaced regularly.