Duration: 10:30 UTC, February 6 - 15:57 UTC, February 8 (~51 hours including investigation; active disruption was intermittent)
Impact: Customers using Intercom's WhatsApp channel experienced intermittent failures receiving inbound media attachments
On February 6, 2026, some customers using Intercom's WhatsApp channel began experiencing intermittent failures when receiving inbound media attachments, most notably audio and voice messages, though other media types were also affected. Text messages continued to function normally throughout the incident.
Media messages that failed during the incident were queued and successfully reprocessed after the fix was deployed.
We understand that WhatsApp is a critical communication channel for many of our customers, and that the inability to receive media from your end users directly impacts your support operations. We sincerely apologize for the disruption this caused.
Root Cause Analysis
High-level summary
Intercom's WhatsApp integration retrieves media files (images, audio, video, documents) from Meta's servers when your end users send them. To do this, Intercom makes API requests to Meta's Graph API on your behalf.
The root cause was a subtle issue in how Intercom's code specified the type of API request when retrieving media. An internal data type inconsistency caused our HTTP client library to construct the request differently than intended. Instead of sending a standard retrieval request (HTTP GET), the library fell back to sending a different request type (HTTP POST) that Meta's media endpoint does not accept. Meta's servers responded with a "Method Not Allowed" error, and the media could not be retrieved.
This issue was intermittent rather than a complete outage. Our investigation indicates that the behavior of the request varied depending on which upstream server processed it, leading to inconsistent outcomes across attempts. This made the failure difficult to reproduce consistently and complicated initial diagnosis.
Why does this affect customers?
When someone sends you a WhatsApp message containing media, a voice note, an image, a document, Meta's servers host that media temporarily. Intercom must retrieve the media from Meta's servers and attach it to the conversation in your inbox.
When this retrieval fails, the media attachment is not available in the conversation. In practice, customers experienced:
Voice messages and audio files not appearing in conversations
Some images and documents intermittently failing to load
Conversations appearing with missing attachments
Text-only messages were unaffected because they do not require a separate media retrieval step.
Technical deep dive
Intercom passed the HTTP method to the Koala library (Ruby client for Meta's Graph API) as a symbol (:get) instead of a string ("get"). Koala doesn't recognize symbols, so it silently fell back to sending a POST with method=get in the body, a legacy Graph API convention.
Meta's media endpoint expects a GET and returns 405 Method Not Allowed for POST requests. The legacy method=get body parameter was honored inconsistently, which explains the intermittent nature of the failure.
The fix normalizes the method to a string before passing it to Koala, ensuring a standard GET is always sent.
Timeline (UTC)
Feb 6, ~10:30: Media retrieval failures begin; failed messages begin queuing
Feb 6, 12:44: Automated alerting triggers; engineering team begins investigation
Feb 6, ~13:30: Failures confirmed as isolated to inbound WhatsApp media retrieval
Feb 6, ~15:20: Additional logging deployed; issue confirmed across all media types (intermittent)
Feb 6, 16:06: Media retrieval temporarily disabled to prevent further queuing of failed messages
Feb 6, ~17:16: Root cause identified as HTTP method type mismatch
Feb 6, 17:26: Candidate fix written and submitted for review
Feb 8, ~15:10: Fix deployed to production behind a staged rollout
Feb 8, 15:22: Fix verified on test workspace; errors confirmed resolved
Feb 8, 15:26: Fix enabled globally; media retrieval errors drop to zero
Feb 8, 15:57: Incident resolved; monitoring confirms full recovery
Feb 9, ~10:26: All queued messages from the incident period successfully reprocessed with no errors
Resolution
On Feb 6, media retrieval was temporarily disabled via a feature flag to stop failed messages from accumulating, ensuring new inbound media was queued rather than repeatedly failing. On Feb 8, a code fix was deployed that corrected the HTTP method type, ensuring the correct GET request is sent to Meta's API. The fix was rolled out incrementally, first to an internal test workspace, then globally, to minimize risk. Once the fix was fully rolled out, all new messages were processed as expected and the active incident was resolved. By Feb 9, all queued media messages had been reprocessed successfully and customers received the previously-failed attachments in their conversations.
Next steps
Completed remediation
Root cause fix deployed
The code change that corrects the HTTP method type has been deployed to production and is no longer behind a feature flag. The fix is permanent and applies to all media retrieval requests.
Queued messages reprocessed
All media messages that accumulated during the incident have been successfully reprocessed and delivered to affected conversations.
Ongoing improvements
External API request validation
We are adding validation to ensure that HTTP request parameters conform to expected types before they are sent to external APIs. This will catch similar type mismatches before they reach production.
Improved resilience for media retrieval
We are implementing circuit breaker protections for external API calls in our WhatsApp media pipeline. This will allow the system to gracefully degrade and recover more quickly when external services return unexpected errors, rather than repeatedly retrying failed requests.
Earlier detection
We are reviewing our alerting thresholds for the WhatsApp message processing pipeline to ensure that failures are detected earlier, reducing the time between an issue occurring and our engineering team being notified.
Contextualizing this incident
This incident affected a specific function within the WhatsApp channel, inbound media retrieval, while text messaging and other channels remained fully operational. The intermittent nature of the failure, caused by inconsistent behavior across Meta's server fleet, made initial diagnosis more complex than typical issues.
We are committed to the reliability improvements outlined above and to ensuring that our integration with Meta's WhatsApp platform is resilient to this class of issue going forward.