'The Application Did Not Respond': Fix Discord Error 10062

You run a slash command and Discord answers with "The application did not respond". Under a button it says "This interaction failed" instead. In your bot's console, if anything shows up at all, it is DiscordAPIError[10062]: Unknown interaction. Each message points to a different spot between Discord and your code. Below are the exact strings, what each one means, and code that works in discord.js 14.28.0, the latest version on npm on 3 November 2026.

Quick answer: Discord gives your bot 3 seconds to send the first response to an interaction. If no valid response arrives in time, the user sees "The application did not respond" (or "This interaction failed" on buttons and select menus) and the interaction token is invalidated, so a late reply fails with DiscordAPIError[10062]: Unknown interaction. The usual causes are slow work before the first reply, a second copy of the bot handling the same interaction, a blocked event loop, autocomplete or modals (which cannot be deferred), and a bot that never received the interaction. Make await interaction.deferReply() the first await in slow commands, run one copy of the bot, and read your log to see which case you have.

What "The Application Did Not Respond" and Error 10062 Mean

Discord's interaction docs say you "must send an initial response within 3 seconds of receiving the event", and "if the 3 second deadline is exceeded, the token will be invalidated." Once a valid first response is in, you can keep using the token for edits and follow-ups until its 15 minutes are up. Our guide to rate limits and gateway timeouts covers the deadline in depth; this post sticks to the error messages.

The numeric codes are listed in Discord's JSON error codes. The two text errors are thrown by discord.js itself before any request goes out (Messages.js in 14.28.0).

The split that saves the most time: if the user saw "did not respond" and your log shows 10062, your bot received the interaction and answered too late (causes 1, 3 and 4 below). If your log shows 40060 or 10062 while users still get answers, look at cause 2. If your log shows nothing at all, the interaction never reached your handler (cause 5).

Cause 1: Slow Work Before the First Response

Anything you await before the first reply counts against the 3 seconds: a database query, another API, an AI model, a big file read. If that call is usually quick but sometimes slow, the command fails only some of the time, which is why this error often seems random.

The fix is to acknowledge first and work second. deferReply() sends the response Discord calls DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE, and the user sees "is thinking..." while you have 15 minutes to edit in the result:

const { Events, MessageFlags } = require('discord.js');

client.on(Events.InteractionCreate, async (interaction) => {
  if (!interaction.isChatInputCommand()) return;
  if (interaction.commandName !== 'stats') return;

  // First await in the handler: acknowledge before any slow work
  await interaction.deferReply({ flags: MessageFlags.Ephemeral });

  const stats = await loadStatsFromDatabase(interaction.user.id);
  await interaction.editReply(`You have ${stats.points} points.`);
});

Three details trip people up:

• Defer first, not after the slow part. A discord.js maintainer put it plainly in issue #7005: "Deferring is the first action you should be doing, not the last."
• Await the defer. discord.js marks the interaction as deferred only after Discord accepted the defer (InteractionResponses.js). Call editReply() without awaiting deferReply() and you get InteractionNotReplied.
• Choose ephemeral in the defer. The discord.js guide notes that you cannot change the ephemeral state afterwards. In 14.x the old ephemeral: true option is deprecated and prints a warning; use flags: MessageFlags.Ephemeral.

For a button or select menu that should update its own message, deferUpdate() acknowledges without a loading state; edit later with editReply().

Cause 2: Two Copies of the Bot, or Two Handlers

Every copy of your bot that is logged in with the same token receives the interaction. The fastest one responds, and the others get 40060 Interaction has already been acknowledged or 10062. Users may even get an answer from the old copy, running last week's code. Common ways this happens:

• The bot still runs on your PC (or in a forgotten terminal) after you moved it to a host.
• A process manager starts several instances. PM2's cluster mode with pm2 start app.js -i max runs one process per CPU core, each one a separate login.
• A deploy starts the new process before the old one has stopped.

Add a log line that shows which machine and process handled each interaction:

const os = require('node:os');

client.on(Events.InteractionCreate, (interaction) => {
  const ageMs = Date.now() - interaction.createdTimestamp;
  console.log(
    `[${os.hostname()} pid ${process.pid}] ${interaction.id} ` +
    `${ageMs} ms old on arrival, ws ping ${client.ws.ping} ms`
  );
});

If one interaction ID shows up from two hostnames or process IDs, you found it. A quicker test: stop the bot on your host and run a command. If something still answers, another copy is running. If you cannot find it, reset the token in the Developer Portal so the forgotten copy cannot log in with the old one.

Two handlers in one process do the same. A collector and a global interactionCreate listener both fire for the same interaction, and a discord.js maintainer confirmed in issue #6123 that the two "don't know of the existence of one another". If both reply, the second gets InteractionAlreadyReplied, or 40060 when both replies are sent at the same moment (discord.js sets its flag only after Discord answers). Let exactly one code path respond to each interaction.

Cause 3: Autocomplete and Modals Cannot Be Deferred

Two interaction types have no "wait" option.

Autocomplete. The discord.js autocomplete guide says autocomplete interactions "must receive a response within 3 seconds. You cannot defer the response to an autocomplete interaction." It suggests a local cache for suggestions that come from an API, and you can return at most 25 choices:

const namesCache = ['Survival', 'Creative', 'Skyblock']; // fill and refresh this on a timer, not per keystroke

client.on(Events.InteractionCreate, async (interaction) => {
  if (!interaction.isAutocomplete()) return;

  const typed = interaction.options.getFocused().toLowerCase();
  const choices = namesCache
    .filter((name) => name.toLowerCase().startsWith(typed))
    .slice(0, 25)
    .map((name) => ({ name, value: name }));

  await interaction.respond(choices);
});

Modals. The modals guide says "showing a modal must be the first response to an interaction. You cannot defer modals." So deferReply() followed by showModal() throws InteractionAlreadyReplied, and a database lookup before showModal() can push you past 3 seconds. Show the modal straight away and do the slow work in the modal submit handler, where deferReply() works again. Discord's response type table marks the modal response "Not available for MODAL_SUBMIT and PING interactions", so you cannot answer a submitted modal with a second modal.

Cause 4: A Blocked Event Loop or a Late Connection

Sometimes deferReply() is the first line and you still get 10062. Then the interaction reached your code late, or your code could not run.

Node.js runs your handlers on one thread, and the Node.js event loop guide explains that while it is blocked, "it cannot handle requests from any other clients." A long synchronous loop, JSON.parse on a huge file, image generation or a sync file read in one command delays every interaction that arrives meanwhile. Move heavy work to a worker thread or another process.

The log line from cause 2 measures this. createdTimestamp comes from the interaction's ID, a snowflake that holds the time Discord created it, so ageMs shows how much of the 3 seconds was gone before your handler started. It is only accurate when your server's clock is synced; on Linux, timedatectl should show System clock synchronized: yes.

• Every interaction arrives old and client.ws.ping is high: the gateway connection is slow or reconnecting. Check the host's network and CPU load.
• Ages jump only around certain commands: those commands block the event loop.
• Ages are low but 10062 stays: something runs before your defer (cause 1).

Cause 5: The Interaction Never Reaches Your Code

No error in the log, but users see "The application did not respond". Check these in order:

1. Is the bot online? Interactions sent through the gateway reach connected clients only. A crashed process, a free host that put the bot to sleep, or a PC that went into standby means nobody receives them. On our Discord bot hosting the paid plans have no sleep mode and restart the bot automatically after a crash; our auto-restart guide covers what a restart does and does not fix.
2. Is an Interactions Endpoint URL set? Discord delivers interactions either over the gateway or to an HTTP endpoint, and the docs call these "mutually exclusive". If the Interactions Endpoint URL field on your app's General Information page in the Developer Portal is filled, a gateway bot receives nothing. Clear it.
3. Did the user pick the right app's command? Commands belong to the application that registered them. With a test bot and a production bot in one server, each has its own copy of the commands, and Discord sends the interaction to the app whose command the user picked. If that app is offline, nothing answers.
4. Does your handler skip it? A handler that starts with if (!interaction.isChatInputCommand()) return; ignores buttons, so a button without its own handler shows "This interaction failed". The handler from the discord.js guide also returns without replying when a command name is unknown, which happens after you rename a command but before the new list is deployed.

An Error Handler That Does Not Make It Worse

The guide's error handler sends an error message with followUp() or reply(). After a 10062 that fails too, because the token is gone, and without a catch Node.js treats it as an unhandled rejection. In the default mode, throw, that is raised as an uncaught exception and the process stops: one late interaction takes the whole bot offline. This version logs the real error and skips the hopeless reply:

const { Events, MessageFlags, RESTJSONErrorCodes } = require('discord.js');

client.on(Events.InteractionCreate, async (interaction) => {
  if (!interaction.isChatInputCommand()) return;

  const command = client.commands.get(interaction.commandName);
  if (!command) {
    await interaction.reply({ content: 'This command is not available.', flags: MessageFlags.Ephemeral });
    return;
  }

  try {
    await command.execute(interaction);
  } catch (error) {
    console.error(`/${interaction.commandName} failed (interaction ${interaction.id})`, error);

    // An expired token cannot be answered: replying again only fails again
    if (error.code === RESTJSONErrorCodes.UnknownInteraction) return;

    const message = { content: 'Something went wrong. Please try again.', flags: MessageFlags.Ephemeral };
    try {
      if (interaction.replied || interaction.deferred) await interaction.followUp(message);
      else await interaction.reply(message);
    } catch (replyError) {
      console.error('Could not send the error message', replyError);
    }
  }
});

RESTJSONErrorCodes.UnknownInteraction is 10062. After a few days, the logged errors tell you which cause you have and how often.

FAQ

Why does Discord say "The application did not respond" when my bot is online? Either it answered after 3 seconds (your log then shows 10062), or the interaction never reached your handler: check the Interactions Endpoint URL, which app's command was used and early returns in your handler (cause 5).

Does deferReply fix DiscordAPIError[10062]: Unknown interaction? Only if the defer itself reaches Discord within 3 seconds. Make it the first await in the handler. If 10062 comes from deferReply() itself, the delay happens before your code runs, usually a blocked event loop or a slow connection. The age log in cause 2 shows how late the interaction arrived.

What is the difference between error 10062 and 40060? 10062 means the token is no longer valid, usually because 3 seconds passed. 40060 means something already acknowledged the interaction: your own code or another copy of the bot.

How long can a deferred reply take? Up to 15 minutes: Discord's docs give interaction tokens a lifetime of 15 minutes. After that, editReply() and followUp() fail with DiscordAPIError[50027]: Invalid Webhook Token, as in discord.js issue #10413. For longer jobs, send the result as a normal channel message or a DM.

How do I fix 10062 in discord.py? The error looks like discord.errors.NotFound: 404 Not Found (error code: 10062): Unknown interaction, and the causes are the same. Call await interaction.response.defer() first (with thinking=True for a component that should show the loading state), then send the result with await interaction.followup.send(...). In discord.py 2.7.1, defer() works for application commands, components and modal submits (interactions.py).

Sources

All opened on 3 November 2026:

• Discord developer docs: Receiving and responding to interactions, Interactions overview, Opcodes and status codes, Reference: snowflakes
• Discord API docs issues with the client messages: #7067 "The application did not respond", #6317, #3177 "This interaction failed"
• discord.js: 14.28.0 release, npm package, Messages.js, InteractionResponses.js, DiscordAPIError.ts, issues #7005, #6123 and #10413
• discord.js guide: Response methods, Command handling, Autocomplete, Modals, Component interactions
• discord.py 2.7.1: interactions.py, errors.py
• Node.js: Don't block the event loop, --unhandled-rejections
• PM2: Cluster mode