How to Check Whether an n8n Workflow Is Already Running

Define the question first

What counts as “already running”?

Teams use the phrase for several different states. Choose the state that represents a conflict for the workflow’s real action before building a filter.

A workflow that waits three days for approval should not necessarily block every new submission for three days. Conversely, a queue of accepted executions may represent pending duplicates even though only one is actively running. Define the protected scope too: “any execution of this workflow,” “any execution for this customer,” and “any execution for this order ID” are different questions.

If the symptom is simply that two scheduled windows overlap, the evidence and fix ladder are covered in How to Stop Overlapping n8n Workflow Executions. This guide focuses on how to inspect or automate the running-state decision.

Best first diagnostic

Manual check in the workflow Executions tab

Open the workflow and select its Executions tab. n8n provides workflow-level and instance-level execution lists; use the workflow-level view when you need to isolate one workflow. Filter the list by active status and inspect the start time, duration, mode, and execution ID.

1. 01

   Open the affected workflow

   Use the workflow whose ID and published version produce the action. A similarly named copy is a separate workflow and will have separate execution records.

2. 02

   Filter active statuses

   Select Running. Add Waiting when paused executions still hold the resource you want to protect. On n8n Cloud, the executions view also exposes active execution and concurrency information for the plan.

3. 03

   Compare timestamps

   An older execution with no stop time confirms active or stale work. Two start times close together confirm separate executions; duplicate items inside one execution are a different data-shape problem.

4. 04

   Inspect the last completed node

   Open the active execution and identify whether it is doing work, waiting by design, retrying, or stuck at an external call. Do not stop it until you know whether termination can leave partial side effects.

Automate observation carefully

Automated execution-status check

n8n’s authenticated API can list executions, and current documentation defines execution permissions for listing and reading execution metadata. Use the public API reference available on your instance to confirm the endpoint and parameters for that version. The logical query is:

workflowId = the protected workflow
status = running
limit = a small bounded result set

If waiting work should also count, query waiting as a separate active state or use the documented multi-status capability available to your interface. Request metadata only; payload data is unnecessary for a running-state decision and may contain sensitive information.

The self-match problem

When the workflow checks its own executions after it has started, the query may correctly return the current execution. Exclude the current ID, available in expressions through $execution.id, before deciding that an older run exists. In pseudocode:

conflicts = executions.filter(execution =>
  execution.id !== $execution.id &&
  ["running", "waiting"].includes(execution.status)
)

Do not paste an API key into a Code node or article expression. Store it in an n8n credential used by the HTTP Request node, grant only the scopes needed to list execution metadata, and avoid logging authorization headers. If the checker runs in a separate monitoring workflow, it does not need to exclude itself unless it queries its own workflow ID.

Filter by business scope, not only workflow ID

An execution-list query tells you that the workflow is active, but execution metadata alone may not tell you which customer, file, order, or tenant it is processing. If independent keys may run safely in parallel, a workflow-wide check is too broad. Maintain a small lock or job table keyed by the protected business identifier instead of fetching full execution payloads just to infer scope.

Observation is not exclusion

Why “check, then run” can still overlap

Suppose executions A and B start within milliseconds. A queries active executions before B appears in the result. B performs the same query before A’s status is visible or before either writes a guard. Both see no conflicting older run and both continue. Even if the status API is perfectly accurate, the decision and the protected action are separate operations with a gap between them.

This is why a status query is excellent for dashboards, operator alerts, conditional notifications, and low-risk best-effort skips, but insufficient by itself for charging a card or provisioning the same account once.

Choose the least risky control

Safer guard patterns

Pattern A: widen the interval or bound runtime

For a scheduled batch where every run processes the same global resource, the simplest correction may be a longer schedule interval, smaller pages, per-node timeouts, or a workflow timeout. This reduces overlap but does not defend against manual starts, retries, or unusually slow runs. Use the dedicated Schedule Trigger checklist to rule out duplicate schedules first.

Pattern B: durable workflow-wide lease

Create one lock record for the workflow, with an owner execution ID and an expiry or review timestamp. The acquisition must be atomic: only one execution can create or transition the record into the owned state. Release it on confirmed completion. For expired leases, reconcile the previous action before allowing a replacement owner; time passing does not prove the old side effect failed.

Pattern C: keyed claim per customer or event

If different customers can safely run together, key the claim by customer, order, file, or event instead of workflow ID. This preserves useful concurrency while preventing the specific collision that matters. The reusable architecture in How to Prevent Duplicate Webhook Executions in n8n applies the same principle to webhook event IDs.

Pattern D: instance concurrency control

n8n Cloud applies plan-based concurrency limits to production executions in regular mode; executions beyond the limit queue and later run in FIFO order. Self-hosted concurrency controls and queue-mode worker concurrency manage capacity differently. These controls protect instance stability and throughput. They are not a substitute for a business-key lock: queued duplicates still run later unless the workflow identifies them.

Test both visibility and exclusion

Verification checklist

• The workflow-level Executions tab shows the expected active status and execution ID while the test run is paused at a controlled Wait node.
• The automated query returns that test execution when filtering by the correct workflow ID and status.
• A self-check excludes $execution.id and does not block itself merely because it is running.
• Your definition of active explicitly includes or excludes waiting and queued work.
• Two near-simultaneous test starts cannot both acquire the same durable lock or business key.
• A different business key can proceed concurrently when that is intended.
• Stopping or crashing the owner produces a documented recovery state rather than leaving an invisible permanent lock.
• API credentials use the minimum required permission and execution payload data is not retained unnecessarily.

Short answers

FAQs

Can an IF node check whether another execution is running?

An IF node can branch on data returned by an earlier API or datastore lookup, but it does not independently inspect all n8n executions. More importantly, the branch is only as race-safe as the operation that produced the data.

Should Waiting executions count as running?

Count them when they still own the same protected resource or when a second run would create a conflict. Exclude them when each waiting execution represents an independent item, such as separate approvals.

Does setting concurrency to one solve the problem?

It can serialize a defined execution pool, depending on deployment and feature scope, but serialization is not deduplication. Two duplicate events can still execute one after the other and repeat the side effect.