How long an execution can run

A workflow can take seconds or it can take hours. Sending an email finishes right away; a nightly sync walking thousands of orders against an ERP does not.

Floogos applies a maximum time per execution so a badly built flow can’t run forever. This page explains how that limit works, what you see when it fires, and how to fit it to your real processes.

In one sentence

By default, an execution can run for up to 1 hour. If you need more, raise the limit or remove it. And the limit never cuts a node in half.

---

What happens when time runs out

The execution is marked as failed and recorded with the reason:

Maximum execution time exceeded (3612s)

From there:

Completed work isn't lost

Nodes that already finished left their result and their trace behind. You can see exactly where it stopped.

You get notified

If you have an Error Trigger set up, it fires just like with any other failure. No silent stops.

---

The cut isn’t instant (and that’s deliberate)

This is the part that surprises people most, so it’s worth understanding.

Floogos checks the time between one node and the next, never in the middle of one. If the limit expires while a node is working, the engine waits for that node to finish and cuts right after.

1. The limit expires at 60 minutes.

2. But a SQL query is running and has been going for 3 minutes.

3. The engine waits for the query to return.

4. It cuts there, and the error records the real time: 63 minutes.

That’s why it’s normal to see a time slightly higher than the configured limit. It isn’t a precision problem: cutting a node in half would leave open transactions, half-written files, or API calls with no response.

Practical consequence

If a single node takes a long time — a heavy query, a slow API — the cut is delayed until that node finishes. If you need to actually cut off a slow node, the limit belongs on the node itself (for example, the SQL query timeout), not on the execution.

---

How to change the limit

Raise it

If you have long, legitimate nightly processes, set a value that matches. A job walking an entire ERP may need several hours.

Remove it

You can run with no time limit at all. It isn’t risky: the real brake against loops is a different one, and it stays active (see below).

On-premise installations only

Environment variables are set on the server where Floogos runs, so they apply to on-premise installations. On Floogos Cloud you don’t have access to them — these values are managed by the Floogos team. If you need one changed for your account, get in touch with support.

It’s controlled by these two environment variables:

Variable	What it does
WORKFLOW_MAX_EXECUTION_SEC	Sets the limit for all executions. 0 = no limit.
WORKFLOW_DEFAULT_EXECUTION_SEC	The default limit when nothing else is defined. Defaults to 3600 (1 hour).

0 means no limit

Both 0 and negative values are read as no time limit. If you don’t want any cap, WORKFLOW_MAX_EXECUTION_SEC=0 is the explicit way to say so.

---

Why removing the limit isn’t dangerous

The fair question is: if I remove the time limit, what protects me from an infinite loop?

The node budget, which is a separate defence and keeps working even with no time limit.

Time limit

Measures how long the execution runs.

A legitimate process can run for hours → this limit gets in the way if it’s too low.

Node budget

Measures how many steps it runs (10,000 by default).

A legitimate process doesn’t run 10,000 nodes → this limit only catches loops.

An infinite loop runs nodes non-stop, so it hits the node budget within seconds, long before any time limit matters. A slow but correct process runs few nodes over a long period: it never comes close to the node budget.

That’s why time is the less important of the two brakes, and why raising or removing it doesn’t reopen the risk of a runaway execution.

Looping sub-workflows

If the loop is between workflows (one calls another that calls the first again), what kicks in is anti-recursion and the depth limit, not time. They’re covered in the execution safety net.

---

What to check when a flow gets cut

1. Read the error message. It distinguishes between running out of time and exceeding the node budget, and those are very different problems.

2. If it’s time: check whether the process is legitimately long. If it is, raise the limit. If it shouldn’t take that long, the problem is a slow node — usually a query without an index or an API that isn’t responding.

3. If it’s the node budget: it’s almost always a loop. Check that no node points backwards in the chain and that iterations have an exit condition.

4. Look at where it stopped. The trace shows the last node executed: that’s the one to review first.

---

Keep reading

• Execution safety net — the six defences that stop a runaway workflow from affecting the platform.
• Sub Workflow best practices — how to chain workflows without creating cycles.
• Retry queue — what happens to an execution that fails.