N8n Queue Mode: How to determine the last successfully executed node when Redis disconnects?

Questions
1

I’m running n8n in Queue Mode (Redis + Worker + Database) and encountered an issue where I cannot reliably determine the last executed node when Redis becomes unavailable.

Describe the problem/error/question

During workflow execution, if Redis disconnects or restarts, the following behavior occurs:
The execution remains in running state in the database
No execution progress is visible in the UI
After Redis recovers, execution does not resume or update progress
After restarting the main n8n instance, the execution status is updated to crashed
However, the UI and execution data do not clearly show which node the workflow stopped at

Information on your n8n setup

  • n8n version: 2.11.4
  • Database (default: SQLite): pgsql
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system:

Question

  1. Is there any official or recommended way to determine the last successfully completed node in this scenario?
2

Hi @halouprogramer

Your n8n setup uses Redis as a “messenger” to coordinate work between the main system and the workers. When Redis disconnects, the messenger disappears, meaning the main system never receives the signal that a task has finished. This leaves the task stuck in a “running” state. When you restart the system, n8n notices the task never officially ended and marks it as “crashed” as a way of cleaning up.

Although the task is labeled as “crashed,” n8n usually saves the results of each individual step (node) to your database as it goes. The problem is that the n8n user interface is not designed to show this partial progress for crashed executions. This is why the UI looks blank or doesn’t highlight where the workflow stopped, even though the data actually exists.

To find out exactly which node was the last to finish, you need to bypass the user interface and look directly at your PostgreSQL database. By searching for the specific execution ID in the database tables, you can see the raw data for that run. The last node that successfully saved its output to the database is the one where the workflow stopped.

SELECT data 
FROM execution_entity 
WHERE id = YOUR_EXECUTION_ID;

Note: Run the following query in your Postgres instance (replace YOUR_EXECUTION_ID with the actual ID)

To stop this from happening in the future, you can adjust a few settings to make your system more resilient. Increasing the Redis timeout gives n8n more time to recover from brief network glitches, and setting a maximum “Execution Timeout” ensures that stuck tasks are automatically closed rather than hanging in a “running” state indefinitely.

3

Welcome to the community @halouprogramer!

In queue mode, what you are seeing is unfortunately expected: once Redis drops mid‑execution, the main instance never gets a clean “I’m done” signal from the worker, so the run stays in “running” until something cleans it up, and when it does get cleaned up it’s marked as “crashed” without node‑level context in the UI.

If you really need to know “where did this stop?”, you basically have two options:

  • Going forward: turn on “Save Execution Progress” for this workflow, so n8n writes out data after each node and you can see the last completed node even when the final status is crashed.

  • Right now / retroactive: query your Postgres execution_entity for the specific execution ID and inspect the data payload directly – that raw JSON usually contains the last node that managed to persist its output, even though the UI does not surface it for crashed runs.

Beyond that, the only real fix is keeping Redis stable (timeouts, reconnection, infra side), because as long as the “messenger” can randomly disappear, n8n has no reliable way to close the loop and mark the execution with an accurate final state.

4

I would treat this as an observability and recovery-design problem, not just a Redis problem. For production workflows, add checkpoint logging around critical nodes so you can tell what completed even if the execution UI only says crashed. Then review queue/worker restart behavior and Redis persistence, because without checkpoints the workflow can fail in the worst possible way: half-done with no obvious resume point.