IFTTT webhook action terminates after ~60 seconds with no cancellation signal

Answer – IFTTT does not send a header or status code when a webhook action times out.

When an IFTTT applet triggers a Webhooks action that runs longer than the platform’s hard wall‑clock limit (≈60 seconds), the request is simply aborted. IFTTT closes the TCP connection after the timeout and logs an error in the Activity feed. No custom header, status code, or cancellation signal is sent to the endpoint.

Key Facts

• All built‑in actions—including Webhooks, Email, Notifications, and third‑party services accessed through IFTTT—share the same 60‑second cap.
• The limit is enforced uniformly across free, pro, and higher‑tier accounts; it is not user‑configurable.
• When the timeout occurs, IFTTT’s only observable effect is the "Action failed" entry in the Activity feed; the HTTP response is never delivered.
• Because the connection is dropped, the endpoint may see the request terminate abruptly (e.g., a socket close) but receives no explicit signal indicating a timeout.

Detecting an Abort on Your Endpoint

1. Log request start and end times. If the endpoint’s logs show a start timestamp but no corresponding completion record within ~60 seconds, the request was likely aborted by IFTTT.
2. Check the socket state. A closed socket or a read/write error after ~60 seconds can confirm a timeout.
3. Use a short‑lived acknowledgement. Respond with a 200 OK immediately and offload heavy work to a background worker. This guarantees the IFTTT call succeeds even if the heavy task is still running.

Mitigation Strategies

• Split the work. If a task naturally takes longer than 60 seconds, break it into smaller steps and trigger multiple applets or use a queue.
• Offload to a separate service. Have the webhook call a lightweight endpoint that enqueues a job, then returns instantly.
• Implement idempotency. If a request is retried after a timeout, ensure the operation can be safely repeated without side effects.

What IFTTT Offers for Endpoints

There are no built‑in mechanisms for an endpoint to learn that an action was aborted beyond the Activity feed logs. The only way to infer a timeout is by observing the abrupt termination of the HTTP connection or by checking the absence of a completion record in your logs.

Next Steps for Developers

1. Modify your webhook to respond quickly (≤1 second) and delegate long processing to a background job.
2. Implement logging of request start, completion, and any socket errors to detect timeouts.
3. Monitor IFTTT Activity feed for "Action failed" entries to correlate with your endpoint logs.