Investigating a Cloudflare Workers AI failure

An error from an AI provider gives you two immediate questions: which requests are failing, and which parts of your product depend on them? A vendor’s overall status is useful context, but it cannot answer either question for your application.

For a team using Workers AI, start with the specific model and operation. Cloudflare’s Workers AI binding documentation (opens in new tab) shows that a call names its model explicitly. Keep that model identifier alongside your error records so an embedding failure does not get mixed in with an unrelated generation request.

Establish what failed

Record the request time in UTC, model identifier, error or response code, and the affected application path. Compare failed requests with successful ones from the same period. Avoid recording prompts, credentials, or customer content when request metadata is enough to investigate.

Check Cloudflare’s status page (opens in new tab) for a relevant incident and its updates. Save the incident link if there is one. If the vendor has not published an incident, keep that separate from what your own requests show. Neither a green status page nor a failed request on its own establishes the scope of an outage.

Find the product dependency

An embedding request might sit on the path for search, retrieval, or background indexing. Those paths need different responses. A delayed indexing job may be retried later; an interactive request may need a clear error or a fallback you have already tested.

Trace the failing call through your code and deployed configuration. Check the model, endpoint and operation it uses. A package name alone does not establish which model runs in production, especially when configuration supplies that choice.

Decide what to do with the evidence

Use your application’s behaviour to choose the response. Check whether retries are bounded, whether a cached result remains appropriate, and whether the fallback works with the same inputs and outputs. Record the action in the incident timeline so another engineer can see what changed.

If you are investigating an SLA claim, read the available Cloudflare terms and your own contract. A request failure does not establish credit eligibility: the covered product, measurement definition, exclusions, and required evidence all matter.

For a later review, the Cloudflare reliability page keeps recorded incident history alongside available measurements. Check their observation periods before comparing them with your request records.

Correction, September 6, 2026: removed unsupported detection lead times and customer-impact figures. This is an investigation guide, not a customer case study.