DiscordStatus
Guias / Guides

Error 408 - Read Timed Out

What does it mean

The 408 - Read Timed Out error in Webhook logs indicates that the connection between Asaas and your server was successfully established, but your application did not respond within the expected timeout period.

The event was sent, but Asaas did not receive a success confirmation in time.

How the Asaas timeout works

After sending a webhook, Asaas waits up to 10 seconds for a response from your server.

If an HTTP 200 response is not received within this period, the attempt is considered a failure and the event enters the normal retry flow.

If 15 consecutive failures occur, the Webhook queue will be interrupted.

📘

Important

Asaas considers a webhook successfully processed only when it receives an HTTP 200 response.

When does this error occur?

The most common causes are:

  • excessively long processing times;
  • slow database queries;
  • calls to external APIs during processing;
  • deadlocks or congested internal queues;
  • high CPU or memory consumption;
  • partial application unavailability;
  • synchronous execution of heavy tasks.

Impact on the integration

As long as the endpoint continues to exceed the timeout limit:

  • events will be automatically retried;
  • the queue may be penalized;
  • after 15 consecutive failures, the queue will be interrupted;
  • new events will continue to accumulate;
  • events are retained for up to 14 days;
  • events that remain unprocessed after this period will be permanently deleted.

Therefore, it is important to reduce the endpoint response time.

Common scenario example

Problematic flow:

Asaas
↓
POST webhook
↓
Application receives event
↓
Database query
↓
Calls external API
↓
Generates report
↓
Sends email
↓
Returns HTTP 200 after 15 seconds
↓
Read Timed Out

Although the application eventually responds, Asaas will have already closed the connection and considered the attempt unsuccessful.

Recommended approach

The best practice is to immediately respond to Asaas and process longer operations in the background.

Recommended flow:

Asaas
↓
POST webhook
↓
Persist event
↓
Immediately return HTTP 200
↓
Process in an asynchronous queue
↓
Execute business rules

This approach keeps response times low and makes the integration more resilient.

How to fix it

1. Measure endpoint response time

Check how long your application takes to respond.

Ideally, the response should be sent within a few milliseconds.

2. Avoid heavy processing inside the webhook

Avoid executing:

  • long-running queries;
  • third-party API calls;
  • file generation;
  • email sending;
  • complex tasks.

These operations should be performed later through asynchronous queues.

3. Implement asynchronous processing

The webhook should:

  1. Receive the event.
  2. Persist the required data.
  3. Return HTTP 200.
  4. Process the business logic later.

4. Monitor the application

Check:

  • CPU usage;
  • memory consumption;
  • database response times;
  • latency of external APIs;
  • server logs.

Best practices

  • respond to webhooks quickly;
  • return HTTP 200 as soon as possible;
  • use asynchronous queues;
  • implement idempotency;
  • log processing activities;
  • monitor average response times;
  • avoid direct dependencies on external services while receiving events.

How to verify that it worked

After applying the fixes:

  1. Reactivate the Webhook queue.
  2. Generate a new event.
  3. Check the logs.

If the issue has been fixed:

  • the 408 error will no longer occur;
  • events will be delivered normally;
  • the queue will be processed in chronological order.

Common mistakes

  • responding only after all business logic has finished;
  • waiting for external APIs to respond;
  • executing heavy database queries;
  • generating files or PDFs before returning HTTP 200;
  • confusing event processing with acknowledgment of receipt.

Next steps

If you continue experiencing issues, we recommend consulting: