LINE Messaging API · error code

LINE error request_timeout: Webhook request timed out

RetryableWebhook configuration errors

Last verified against LINE Developers - Messaging API reference (error responses)

What LINE returns
request_timeout

What error request_timeout means

LINE connected to your server and sent the webhook, but your response didn't come back in time. The error statistics page summarizes it as: the bot server "didn't return a response within 2 seconds," and the single documented detail value is Request timeout - "Webhook was sent to the bot server, but no response was returned within a certain period of time."

LINE adds a warning that changes how you debug this: "Note that the webhook may have been successfully received by the bot server." In other words, your handler may well have run - it just answered too slowly. If your bot does slow work (an LLM call, a database write, an outbound API) before returning HTTP 200, the work finishes, the reply may even go out, and the statistics still log a timeout.

That matters doubly if you enable webhook redelivery. A timed-out delivery didn't return a 2xx, so it qualifies for redelivery, and your server can receive the same event a second time with the same webhookEventId and reply token. Without deduplication that produces double processing, and a second reply attempt on an already-used token returns Invalid reply token.

What it looks like

// Webhook errors tab (Error statistics aggregation enabled)
Reason:  request_timeout
Detail:  Request timeout
Errors:  42

Why it happens

  • The handler does slow synchronous work (AI generation, external API calls, heavy queries) before returning 200.
  • Cold starts on serverless platforms push the first request past the time limit.
  • Signature validation or body parsing blocks on a slow middleware chain.
  • The server is saturated, so requests queue before your code runs.

How to fix LINE error request_timeout

  1. 1Return HTTP 200 as soon as the signature is verified, then process events asynchronously; LINE's receiving-messages guide recommends asynchronous processing.
  2. 2Move slow work to a queue or background job and send results with the reply token while it is still valid, or with a push message after it expires.
  3. 3Keep at least one warm instance if you run on serverless, so cold starts don't hit live webhooks.
  4. 4Deduplicate by webhookEventId so a redelivered event isn't processed or replied to twice.
  5. 5Log the time between receiving the request and sending the response and alert when it creeps toward the limit.

How to stop it recurring

Treat the webhook as an acknowledgment endpoint: verify, enqueue, return 200, and nothing else on the request path. Store processed webhookEventId values so redeliveries are harmless. Load-test the endpoint with the response deadline in mind, since a spike in friends or a broadcast campaign is exactly when slow handlers fall behind.

Official reference: LINE Developers - Messaging API reference (error responses). See all LINE error codes or the LINE limits and quotas.

Related codes

Error request_timeout - quick answers

What does LINE error request_timeout mean?

LINE connected to your server and sent the webhook, but your response didn't come back in time.

How do I fix LINE error request_timeout?

1. Return HTTP 200 as soon as the signature is verified, then process events asynchronously; LINE's receiving-messages guide recommends asynchronous processing. 2. Move slow work to a queue or background job and send results with the reply token while it is still valid, or with a push message after it expires. 3. Keep at least one warm instance if you run on serverless, so cold starts don't hit live webhooks. 4. Deduplicate by webhookEventId so a redelivered event isn't…

Can I retry after error request_timeout?

Yes - this is a retryable condition. Back off (start around one second and double on each attempt, with jitter) and watch for a retry-after hint from the platform before resending.

Stop debugging LINE by hand

Connect the channel through Conferbot: tokens, webhooks and retries are handled, failures show as readable status.