## TL;DR
Twilio error 11200 means Twilio tried to fetch your status callback URL and the HTTP request failed. Your texts and calls usually still go out fine, but you never hear back about delivery. The fix is mechanical: make the callback URL publicly reachable over HTTPS, answer fast with a 2xx status, and keep the response body small. Do that and the 11200 warnings stop.

## The error
```text
11200 - HTTP retrieval failure
Attempt to retrieve the URL https://hooks.example.com/twilio/status failed.
```
(Seen in the Twilio console debugger, attached to a message or call SID.)

## Steps
1. Find the failing URL. In the Twilio console, open Debugger, click a 11200 warning, and copy the exact callback URL it tried. Expected output: one full URL, for example https://hooks.example.com/twilio/status.
2. Fetch it from the public internet. Run curl against that exact URL from a machine outside your network. Expected output: an HTTP 200 (or other 2xx) in under a few seconds.
3. Check the certificate. If curl complains about TLS, renew or fix the cert. Expected output: curl finishes with no certificate warnings.
4. Make the handler fast. Log the event to a queue and return 200 immediately; do the real work in the background. Expected output: response time under one second on repeat requests.
5. Open the path to Twilio. If the URL sits behind a firewall, VPN, or basic auth, Twilio cannot get in. Allow the documented Twilio IP ranges or move the endpoint public. Expected output: a request from outside your network with no login prompt returns 2xx.
6. Send a test message and watch the debugger. Expected output: the new message shows status callbacks with no fresh 11200 warnings.

## When to use
- The Twilio debugger shows 11200 warnings after sending messages or placing calls
- Your app never receives status callback posts even though sending works
- You recently changed hosting, domains, TLS, or added a firewall or bot protection
- Callbacks work sometimes and fail other times (cold starts or flaky DNS)

## When not to use
- Messages are not sending at all: that is a sending-side problem, check codes like 30001 or 30007 instead
- MMS media will not download: media fetch failures live in a different code family
- You need the message content back: 11200 is only about the callback transport, not the payload

## Tool compatibility
Twilio Programmable Messaging (SMS and MMS), Programmable Voice, and Twilio Conversations all use status callbacks and can raise 11200. The fix steps work the same whether your receiver is Express, Django, Rails, serverless functions, or a low-code endpoint.

## Variant phrasings
### twilio 11200 meaning
Status callback URL could not be fetched; the send itself usually succeeded.
### twilio status callback never arrives
Same root cause family: unreachable or slow callback endpoint.
### twilio debugger http retrieval failure
The debugger label for 11200, pointing at the exact failing URL.
### twilio webhook timeout
Often the same fix: return 2xx in under a second and queue the work.

## Why it happens
After Twilio sends a message or connects a call, it fires an HTTP POST to your status callback URL to report what happened. That fetch is a plain server-to-server request. Anything that breaks plain requests breaks it: dead DNS, expired certificates, a server that takes 20 seconds to answer, a firewall that only allows your office IP, or basic auth on the path. Twilio records 11200 and moves on. The original send is unaffected, which is why this error is so easy to miss: everything looks fine until you notice you have no delivery data.

## Edge cases
- Works from your laptop but not from Twilio: your laptop is inside the allowed network and Twilio is not. Check IP allowlists and VPN-only DNS.
- Only fails at 3am: serverless cold starts or a host that sleeps. Keep the function warm or move the endpoint to an always-on host.
- Fails after a WAF or bot-mitigation rollout: challenge pages return non-2xx to Twilio. Exempt the callback path from the challenge.
- Redirect chains: Twilio follows a redirect or two, but a chain of them (or a redirect to a login page) fails. Point the callback at the final URL.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0td9kTRFTQtmN4Qyht6iMQ