> For the complete documentation index, see [llms.txt](https://docs.getmesa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getmesa.com/frequently-asked-questions/does-mesa-use-a-durable-queue-and-how-are-retries-and-duplicates-handled.md).

# Does MESA use a durable queue, and how are retries and duplicates handled?

If you're connecting a production system to MESA, you probably want to know what happens when things go wrong. This page covers how MESA's queue handles outages, retries, and duplicate events.

## Is MESA's queue durable?

Yes. When a MESA automation is triggered, the request is placed in a durable, per-store queue rather than processed inline.

You can see queued items on the Activity tab with a "Ready" status.

Because the request lives in the queue first, a temporary outage on MESA's side or a third-party app's side doesn't drop the event, it waits in the queue until it can be processed.

## What happens if MESA or a third-party app is temporarily unavailable?

If a workflow step fails because a connected app (or MESA itself) is temporarily unavailable, the task is marked as failed on the Activity tab. Whether it retries automatically depends on that step's [Failed step handling](https://docs.getmesa.com/workflow-activity/tasks/replay) setting:

* **Automatically replay**: the step retries up to 5 times total, with increasing delays between attempts: 31 seconds, 2 minutes 32 seconds, 5 minutes 4 seconds, then 10 minutes 8 seconds.
* **Log as an error in activity logs**: the step stops and waits for manual replay from the Activity tab. This is the default for most apps. Google Sheets is the one built-in exception that defaults to Automatically replay.

{% hint style="info" %}
For an outage that could last longer than the retry window, we recommend manually triggering Replay from the Activity tab once the service is back, rather than relying solely on automatic retries.
{% endhint %}

## How long are failed or pending events retained?

Retention depends on your MESA plan. This is the window during which a failed or pending task remains visible on the Activity tab and can be manually replayed:

| Plan      | Task history & replay window |
| --------- | ---------------------------- |
| Starter   | 30 days                      |
| Basic     | 30 days                      |
| Flex      | 30 days                      |
| Pro       | 30 days                      |
| Unlimited | 60 days                      |
| Custom    | 90 days                      |
| Affiliate | 30 days                      |

Once a task falls outside this window, it's no longer available to replay from the Activity tab.

## Is there any risk of an order event being permanently lost during an outage?

No, not within your plan's task history & replay window (30, 60, or 90 days depending on plan — see the retention table above).

A failed or pending task stays visible on the Activity tab and available to replay for that entire window, even if the outage on MESA's side or the connected app's side lasts well beyond the automatic retry schedule.

Once a task falls outside that window, it's no longer available to replay.

## Can workflow concurrency be limited so orders are processed sequentially or at a controlled rate?

Yes, and it's actually the default behavior.

To ensure proper message ordering and avoid hitting rate limits on third-party APIs, each store processes one automation run at a time by default. 

If you need higher throughput, MESA can increase the number of parallel queue workers for your store or for a specific workflow (reach out to support to request this).

{% hint style="warning" %}
Increasing parallel workers increases throughput but means runs are no longer guaranteed to complete in strict arrival order relative to each other. If strict ordering matters more than speed for a given workflow, keep it on the default single-worker setting.
{% endhint %}

## Is strict FIFO processing available?

Yes. Each store's queue uses First In First Out (FIFO) ordering by default, so the oldest message is always processed first and the sequence of actions matches the original message order.

This is the default and requires no configuration.

## What about duplicate events?

MESA has built-in handling for one specific and common source of duplicates: Order Updated, Customer Updated, and Product Updated triggers can fire again when only a metafield changes, since metafields live on a separate API payload from the core object.

When this happens within a 24-hour window, MESA marks the run "Skipped" as a duplicate webhook payload, and skipped runs don't count toward usage.

This is not a general-purpose idempotency key across every trigger type. It specifically addresses the metafield-update case. If your workflow needs those metafield-triggered updates to actually run (for example, syncing metafield values to another system), this default can be turned off per workflow (reach out to support to request this).

{% hint style="warning" %}
For workflows where a step updates the same object that triggers it (a common loop pattern), MESA's duplicate handling works in most cases but not all. We recommend adding your own guard: tag or flag the object after your update step, then filter on that tag/metafield at the start of the workflow so a re-triggered run exits early instead of looping.
{% endhint %}