Paused queue

When a Webhook has consecutive delivery failures, Asaas makes new attempts at progressive intervals. After 15 consecutive failures, the queue for that configuration is interrupted.

The interruption occurs per Webhook configuration. Other Webhooks in the same account continue to work normally.

When a delivery is considered successful

To confirm receipt of the event, the endpoint must return:

HTTP 200 OK

Any other HTTP code, including 201, 204, 3xx, 4xx, and 5xx, is treated as a delivery failure.

Connection failures and timeouts also enter the retry cycle.

Understand the intervals and attempts in Queue penalty.

What happens when the queue is interrupted

After 15 consecutive failures:

• no new events from that configuration are sent;
• new events continue to be generated;
• pending events are stored;
• the configuration remains interrupted until it is reactivated;
• events stored for more than 14 days are permanently deleted.

You will also receive email notifications during the failure and interruption process.

How it works: example

%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
A["Send<br/>PAYMENT_CREATED"] --> B["Endpoint returns<br/>HTTP 500"]
B --> C["Make new attempts"]
C --> D["Reach 15 consecutive failures"]
D --> E["Interrupt the queue"]
E --> F["Keep storing<br/>new events"]
F --> G["Fix the endpoint"]
G --> H["Reactivate the queue"]
H --> I["Resume deliveries"]

classDef inicio fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A,stroke-width:3px,font-size:17px
classDef validacao fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E,stroke-width:2px,font-size:17px
classDef sucesso fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:3px,font-size:17px

class A inicio
class B,C,D,E,F,G,H validacao
class I sucesso

linkStyle default stroke:#94A3B8,stroke-width:2px

After reactivation, pending events are processed again.

In Webhooks with Sequential delivery, the order of events is preserved. With Non-Sequential delivery, notifications may be processed in parallel and there is no guarantee of order.

See the Delivery types.

Identify the cause of the interruption

You will receive automatic emails about the failures. You can also check the status of the configuration in:

Integrations → Webhooks

The affected configuration will display the interrupted queue status.

To find the cause, check the Webhook Logs.

The logs let you check:

• the HTTP code returned;
• the error message;
• the time of the attempts;
• the payload sent;
• the number of resends.

Behavior by response type

If the log indicates a specific error, see:

• Error 400 (Bad Request)
• Error 403 (Forbidden)
• Error 404 (Not Found)
• Error 408 - Read Timed Out
• Error 500 (Internal Server Error)
• Connect Timed Out Error
• Other errors

What to do with an interrupted queue

Before reactivating the configuration:

1. check the Webhook Logs;
2. identify the cause of the failures;
3. fix the endpoint;
4. validate that it can receive and persist the event;
5. reactivate the queue.

Your application should persist the event and respond with HTTP 200 without depending on the completion of long-running processing. Run additional rules asynchronously.

Since Webhooks follow the at least once model, implement idempotency to handle possible resends.

See how to implement idempotency in Webhooks.

To reactivate via the dashboard or the API, follow the guide How to reactivate an interrupted queue.

• persisting the event before responding with HTTP 200;
• processing business rules asynchronously;
• monitoring the Webhook Logs;
• implementing idempotency to support resends;
• fixing the cause of the failure before reactivating the queue;
• not leaving the queue interrupted for more than 14 days.

Next steps

• Check the Webhook Logs
• Understand Queue penalty
• Reactivate an interrupted queue
• Implement idempotency in Webhooks
• Understand the Delivery types