n8n API - GET /executions does not return executions with status "waiting" (n8n v1.86.1)

[Mgabr90]

Bug Description

When calling the n8n REST API endpoint: GET /executions, executions whose status is set to "waiting" are never included in the response, even though the endpoint is documented to retrieve all executions.

Environment & Debug Info

Core
─ n8nVersion: 1.86.1
─ platform: npm
─ nodeJsVersion: 20.18.2
─ database: sqlite
─ executionMode: regular
─ concurrency: -1
─ license: enterprise (production)
─ consumerId: 3449b05f-8f7f-4d77-a90a-3c9ddd992333

Storage
─ success: all
─ error: all
─ progress: false
─ manual: true
─ binaryMode: memory

Pruning
─ enabled: true
─ maxAge: 336 hours
─ maxCount: 10000 executions

Client
─ userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
─ isTouchDevice: false

Security
─ secureCookie: false

Generated at: 2025-04-19T16:08:41.082Z

To Reproduce

1. Create a new workflow with a waiting node:

• Add a Manual Trigger node.
• Add a Wait node connected to the Start node.
  In the Wait node, set a wait time (e.g. 1 hour or any delay).
• Click Execute Workflow.
• The execution will start, then pause at the Wait node — it should now be in "waiting" state.
  ✅ Now, an execution will show in the Executions list with "status": "waiting".se the API to check executions:

2. Open the n8n API Docs at:

• http:///api/v1/docs#/Execution/get_executions
• Click Try it out on the GET /executions endpoint and click Execute.
• Examine the response. You’ll see executions with "success", "error" — but none with "waiting".

Expected behavior

The /executions endpoint should include every execution record, regardless of status. Example:

[
  { "id": "1111-aaaa", "status": "success",  /* … */ },
  { "id": "2222-bbbb", "status": "waiting",  /* … */ },
  { "id": "3333-cccc", "status": "error",    /* … */ }
]

Operating System

Ubuntu Linux 22.04

n8n Version

1.86.1

Node.js Version

20.18.2

Database

SQLite (default)

Execution mode

main (default)

[Joffcom]

Hey @Mgabr90,

We have created an internal ticket to look into this which we will be tracking as "GHC-1651"

[Joffcom]

Hey @Mgabr90,

Thanks for reporting this issue! We’ve attempted to reproduce the problem, but unfortunately, we weren’t able to replicate it. It’s possible there was some environmental or other variable that prevented us from seeing the same behavior.

In my test I did a webhook attached to a 1 hour wait node I then called the webhook and made an API request to /executions and I could see the result below in the list, I also got the same result if I added status=waiting to my request.

{
            "id": "26091",
            "finished": false,
            "mode": "webhook",
            "retryOf": null,
            "retrySuccessId": null,
            "startedAt": "2025-04-29T14:03:58.555Z",
            "stoppedAt": "2025-04-29T14:03:58.888Z",
            "workflowId": "HC57JS1iKZRafE78",
            "waitTill": "2025-04-29T15:03:58.868Z"
        },

One difference I can see is I am on a newer version of n8n to you so it could be worth updating to see if that changes anything.

If you’re still encountering this issue, please provide any additional details or steps to reproduce it, and we’d be happy to investigate further. Thanks for your understanding!

[toxsick]

Hey guys, maybe #14237 is related, i am not getting a response there, but I think it could be the same problem,

Thanks and regards

[ffMathy]

Happens for any status. I just get all results instead.

[mybuntu-git2]

I did a test this way.
I set up an http node within n8n with workflowid= "test workflow", following this documentation:
https://docs.n8n.io/api/api-reference/#tag/Execution

the test workflow was set to either wait 30 mins with a wait node (status = waiting), or to wait 30 mins in a code node (so, status = running)

it does not return anything in both cases.

this has been said to be not returning running workflows in the community, but it is a serious limitation.
currently there is no way to spot a dangling execution and kill it.

suppose I trigger from system A a webhook that triggers one main workflow, which spawns 4 subprocesses, that spawn 3 subprocesses each.
at this point, I have 13 running flows.
common situation, one starts to keep running doing nothing because of java goblins

for the sake of the example, let's say it is a filesystem RAG and could run anything from 3 to 30 minutes.

today the only thing I can do is to:

• remove any scheduling job encapsulating the main workflow, and call directly from system A the main workflow
• wait 31 mins and restart N8N if the called workflow is still running.
• design the workflow to heal any issue from stopping the RAG mid-flight.

instead if we were allowed to identify the dangling flow, we could apply some logic for graceful stopping of the executions, before restarting n8n.

[toxsick]

@mybuntu-git2 i used to cancel other executions with waiting status before (see #14237). Some change has broken the expected behaviour recently. Hope someone finds the time to have a look at this anytime soon.

[Joffcom]

As we haven’t heard back from you, we’re going to close this issue to keep things organized. But don’t worry, if you have more information or need further assistance, you’re welcome to reopen the issue anytime or create a new one. We’re always happy to help!

Thanks for reaching out and have a great day! If this was closed by mistake and you have been waiting for us let me know and I can also re-open it.

[toxsick]

Hey @Joffcom, I am waiting for #14237. Don't you think it is related to this?

Greetings!

[Joffcom]

Could be, It is with an internal team to look into but this wasn't something I could reproduce looking at it.