Messenger error 100: Video upload timed out or corrupted

Code 100 with subcode 2018294 is the video-specific failure, and its message contains the number that matters: "Note that if the video can't be fetched within 75 seconds, it will time out." Two distinct conditions share the subcode: Meta's fetcher could not finish downloading your video inside 75 seconds, or it downloaded something it could not process, a corrupted or unreadable file.

The timeout arithmetic is worth doing explicitly. 25 MB (the attachment cap) in 75 seconds needs a sustained ~2.7 Mbps from your origin to Meta's fetchers; a 24 MB video on a throttled origin, a cold serverless function, or an origin an ocean away from the fetcher will lose that race even though every individual requirement looks satisfied. This is why 2018294 is flaky in the way its siblings are not: the same URL can succeed at 3 a.m. and fail at peak.

The corruption half covers truncated uploads (a file whose transfer to your storage was cut short), exotic codecs in an MP4 container, and files whose moov atom sits at the end so that nothing is playable until the last byte arrives, re-encoding with fast-start fixes that. Sitting behind both halves is the same architectural remedy as for 2018008: upload the video once through the Attachment Upload API, let the slow transfer happen out-of-band, and send the reusable attachment_id at conversation speed.

{
  "error": {
    "message": "(#100) Video upload timed out or video is corrupted.",
    "type": "OAuthException",
    "code": 100,
    "error_subcode": 2018294,
    "fbtrace_id": "BLBz/WZt8dN"
  }
}

Standardize bot video at ingestion: transcode to fast-start MP4, cap bitrate so the whole file transfers comfortably inside the window, validate playability, then upload for a reusable ID. Send-time URL fetches should be reserved for small images. The 75-second timeout and 25 MB cap sit together in the Messenger limits reference; the fetch-failure family is compared on the 2018008 page.