Retry Queue (DLQ)

What is the Retry Queue?

When a workflow fails during execution (a node throws an error, an external API doesn’t respond, a piece of data is malformed…), Floogos doesn’t just drop it: it moves the job to a retry queue, also known as a DLQ (Dead Letter Queue).

From there, the system retries the execution automatically, with growing waits between attempts. That way a transient failure (a network blip, a service that was momentarily slow) recovers on its own, without you doing anything.

The Retry Queue gives you visibility into all of this: which workflows are failing, on which node, with what error, how many attempts they’ve used and when the next one is — and it lets you retry or discard jobs manually when you need to.

A workflow that “runs by itself”?

If you notice a workflow firing repeatedly without an active schedule, it’s almost always the Retry Queue retrying a workflow that keeps failing. Open the Retries panel to see it and stop it.

How it works

A failing workflow always follows the same path:

1. Execution fails. The engine catches the error and, instead of losing the work, records the job in the retry queue with status pending.
2. Waits with backoff. The system schedules the next attempt with a wait that grows on each attempt (exponential backoff), so it doesn’t hammer a service that may be down.
3. Retries. When the time comes, the job is re-queued and executed again.
   • If it works, it becomes succeeded and stops there.
   • If it fails again, it counts one more attempt and waits again.
4. Exhausts. After the last unsuccessful attempt, the job becomes discarded: it stops retrying, but is not deleted — it stays in the panel so you can review it or replay it manually.

Retry policy

By default there are 4 retries with these waits:

Attempt	Wait before retrying
1st	1 minute
2nd	5 minutes
3rd	15 minutes
4th (last)	1 hour

If it still fails after the 4th attempt, the job is marked discarded. The number of retries is configurable per installation (DLQ_MAX_RETRIES variable); on-premise can adjust it.

A broken workflow multiplies retries

If a workflow always fails (because of a configuration error, not a transient one), each trigger generates up to 5 executions (the original + 4 retries). If it also fires often, you’ll see many failed executions in a row. The fix isn’t to retry: it’s to fix the cause (the failing node) and discard the pending jobs.

Queue states

Every job in the queue has one of these states:

State	Meaning
Pending (pending)	It failed and is waiting for its next retry. next_retry_at shows when.
Retrying (retrying)	An automatic retry is running right now.
Replaying (replaying)	You are retrying it manually from the panel (the “Retry” action).
Discarded (discarded)	It exhausted all retries (or you discarded it manually). It no longer retries, but stays visible for review or manual replay.
Succeeded (succeeded)	A retry completed successfully. The workflow recovered on its own; it stays in the queue history as resolved.

The normal flow is: pending → retrying → (succeeded or back to pending) → … → discarded if attempts run out.

The panel view

Open it from the side menu, under Retries (Analytics group). The screen has three parts:

Summary cards

At the top, a quick look at the queue state:

• Pending — jobs waiting for their next retry.
• Retrying — jobs running right now.
• Discarded — jobs that exhausted their retries.
• Succeeded — jobs that a retry resolved successfully.
• Last 24h — total jobs that entered the queue in the last day (to spot a spike in failures).

Status filter

Just below, buttons to filter the table by state: All, Pending, Retrying, Discarded or Succeeded. Useful, for example, to see only what’s failing right now.

Jobs table

The detail of each job in the queue:

Column	Content
Workflow	Name and id of the workflow that failed.
Node	The specific node where the error occurred (e.g. editFields_9).
Error	The error message. Hover over it to see the full text.
Attempts	Retries used out of the maximum (e.g. 2/4).
State	The current state (see the states table above).
Next retry	When the next automatic attempt will run.
Created	When the job entered the queue.
Actions	Retry or discard (see below).

The actions (each option)

Retry (per job)

The retry button (↻) on the row re-queues that job immediately, without waiting for its next_retry_at. Use it when you’ve already fixed the cause of the failure (for example, a credential or a piece of data) and want to replay without waiting.

• It is not available for jobs that already succeeded (no need).

Discard (per job)

The discard button (🗑) marks the job as discarded: it stops the retries for that job. Use it when the failure won’t be fixed by retrying (a misconfigured workflow, data that won’t arrive again) and you just want it to stop retrying.

• The job is not deleted: it stays as discarded so you can review it.

Retry pending

The Retry pending button (top right) re-queues all pending jobs at once (up to 50). Useful after resolving a general outage (for example, an external service that’s back up) when you want to replay everything that was waiting.

Refresh

The refresh button (⟳) reloads the cards and the table with the latest queue state.

Best practices

• A spike in “Last 24h” usually points to a downed external service or a change that broke a workflow. Filter by Pending to see what’s failing.
• Before retrying in bulk, make sure you’ve fixed the cause. Retrying without fixing the problem only repeats the failure and wastes resources.
• The same workflow and node repeating in the list (e.g. always editFields_9) points to a configuration or data error, not a transient one: review that node in the editor.
• Discard what you know won’t recover, to keep the queue clean and make alerts reflect real problems.

See also

• Insights and performance panel — metrics and error rate of your workflows.