Error 408 - Read Timed Out

A 408 - Read Timed Out error in the Webhook Logs indicates that the connection to your server was established, but Asaas did not receive the response within the expected time.

How the timeout works

After sending the Webhook, Asaas waits up to 10 seconds for the endpoint's response.

If it does not receive HTTP 200 within this period, the attempt is considered a failure and may be resent.

A response sent after the timeout does not change the result of that attempt. Therefore, do not run long-running processing before confirming receipt of the event.

Read Timed Out or Connect Timed Out?

The two errors indicate different problems.

If the connection was never established, see Connect Timed Out Error.

Main causes

Read Timed Out may occur when the endpoint performs long-running tasks before responding, such as:

• slow database queries;
• calls to external APIs;
• generating files or reports;
• sending emails;
• complex tasks executed synchronously;
• deadlocks or congested internal queues;
• high CPU or memory usage;
• partial application unavailability.

Flow that can cause a timeout

%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
    A["Asaas sends the Webhook"] --> B["Application receives the event"]
    B --> C["Query the database"]
    C --> D["Call an external API"]
    D --> E["Generate a report"]
    E --> F["Send an email"]
    F --> G["Return HTTP 200<br/>after 15 seconds"]
    G --> H["Record<br/>Read Timed Out"]

    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 validacao
    class H sucesso

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

Even if the application responds later, Asaas will already have closed the attempt and may resend the same event.

Recommended flow

Persist the event before confirming receipt and run the business rule in the background.

%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
    A["Asaas sends the Webhook"] --> B["Application receives the event"]
    B --> C["Persist the event"]
    C --> D["Return HTTP 200"]
    D --> E["Process in an asynchronous queue"]
    E --> F["Run business rules"]

    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 validacao
    class F sucesso

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

This flow reduces the endpoint's response time and prevents internal tasks from consuming the 10-second limit.

How to fix it

1. Measure the response time

Monitor the time between receiving the request and returning HTTP 200.

The endpoint must respond within 10 seconds. Reduce this time whenever possible.

2. Persist before processing

When receiving the event:

1. identify the event by the id field;
2. persist the id and the necessary data;
3. confirm the persistence;
4. return HTTP 200;
5. run the business rule in the background.

Since Webhooks use the at least once model, the same event may be resent. Use the id to prevent duplicate processing.

See how to implement idempotency in Webhooks.

3. Remove long-running tasks from the request

Do not wait, before the HTTP 200, for operations such as:

• third-party APIs;
• sending emails;
• file generation;
• slow queries;
• reports;
• other tasks that can be processed later.

4. Monitor dependencies and infrastructure

Check:

• CPU and memory usage;
• database response time;
• duration of executed queries;
• latency of internal services;
• congested queues or workers;
• application logs.

What happens while the timeout persists

Each timeout is treated as a delivery failure.

If the failures continue:

• the event may be resent;
• the configuration enters the progressive penalty mechanism;
• after 15 consecutive failures, the queue is interrupted;
• new events continue to be stored;
• pending events remain available for up to 14 days.

Understand Queue penalty.

How to validate the fix

After making the adjustments:

1. test the endpoint and confirm that it responds in less than 10 seconds;
2. if the queue is interrupted, reactivate the configuration;
3. generate or wait for a new event;
4. check the Webhook Logs;
5. confirm that new attempts return HTTP 200 without Read Timed Out.

The order of deliveries after recovery depends on the delivery type configured in the Webhook. Do not rely on arrival order when using Non-Sequential delivery.

Next steps

• Check the Webhook Logs
• Implement idempotency in Webhooks
• Review how events are received
• Understand Queue penalty
• Reactivate an interrupted queue
• Tell it apart from Connect Timed Out