1. Home
2. Guides
3. Core concepts

When errors happen during the processing of a request, Fastly may generate a synthetic HTTP response and these may be delivered to the end user, often with a 503 (service unavailable) status code.

This page describes the possible conditions that produce this outcome and how to handle such errors at the edge.

Sources of errors

Often you'll become aware of errors in your Fastly service because undesirable HTTP responses (with HTTP status codes of 400 or higher) are being delivered to end users and reported to you.

But this doesn't necessarily mean something is wrong with your Fastly service. HTTP error responses may have a variety of possible causes:

1. Your origin server served it. A well formed, valid HTTP response from your origin server is not considered an error by Fastly (and will not invoke vcl_error in VCL services), though it may itself represent an error that has occurred in your origin server. Unless you configure your service to handle such responses, they will be delivered to end users, and potentially cached.
2. An explicit error statement in your VCL was executed. The error statement can be used in most VCL subroutines to immediately stop the normal VCL workflow, construct a synthetic response object, and transfer control to the vcl_error subroutine.
3. You constructed an error response in a Compute application. Every Compute SDK provides the ability to construct responses from scratch, and you may have a code path that generates an error response.
4. Something happened that caused Fastly to throw an error. These errors are created by Fastly and surfaced in various ways - both in VCL and Compute services. This page describes the possible errors of this type, how they are triggered and how to resolve them.

Fastly-generated errors

These are errors that are generated by Fastly which will halt your program and produce output to the client. Often they will emit output to STDERR too.

End user viewable error policy

Fastly believes that you own the relationship with your customers, and content that end users receive from your website should not be obviously delivered by Fastly. In general, users are not familiar with the role of edge networks, and should not need to be. Therefore, where errors occur and a response must be sent to the client, but your service is not able to produce one itself, Fastly will send a response that is either empty or unbranded.

Routing errors

Fastly may respond to some requests directly from our routing systems, without invoking your service. This often happens when the request is presented on a port that we do not support, or is syntactically invalid. In such cases our response is either to drop the connection or to issue a standards-compliant HTTP error response. The following list itemizes notable responses that may be generated at this layer.

Fastly-generated routing errors may occur when an end user request is presented to a Fastly POP, but also when requests are forwarded from one Fastly service to another (see service chaining) or from one Fastly POP to another (see shielding).

Error responses from our routing systems will either have an empty response body or will cite error 54113, a reference to Fastly's Autonomous System number.

If you see error responses from your Fastly hosted domain and believe these errors are being generated before your code is invoked, contact Fastly support for assistance.

Errors in VCL services

VCL services can generate a number of specific errors that can be handled within VCL code. See Synthetic 503 errors in VCL for details.

Errors in Compute services

Unhandled errors, panics or exceptions in Compute programs usually produce descriptive output on stderr, and if the program terminates before generating a response, will cause a blank HTTP 500 (internal server error) to be served to the client.

stderr output can be captured using log tailing.

The kinds of output produced when programs terminate prematurely is affected by which compiler is used to construct the Compute program (which in practical terms means which language the program is written in). For example, Rust based Compute programs generate panics when they halt abruptly, while JavaScript applications will report unhandled promises, errors, and exceptions.

Platform errors triggered by the Compute platform

In addition to runtime panics and errors in the WebAssembly program, which report their own error states, it's possible for Compute programs to trigger platform errors by invoking Fastly's system interfaces and APIs in unexpected or illegal ways. In such cases the app will produce output on stderr such as "Fastly Error {number}".

If you encounter persistent errors of this kind, please contact Fastly support.

Loop detection

We automatically detect situations where your Fastly service appears to be forwarding requests endlessly to itself. When a loop is detected, Fastly blocks the request at the routing stage and generates a 503 error with a Loop detected reason text. Loops often occur when the same hostname is configured as both the domain and the backend for the same service, and the DNS for the domain resolves to Fastly.

To avoid creating a loop, ensure that traffic from Fastly to your origin server does not inadvertently go back to Fastly. Commonly this is done in one of these ways:

• Use a separate hostname (e.g., origin.example.com) pointing to your origin server, and configure that as the address of the backend in your Fastly service configuration.
• Use an IP address instead of a hostname for your backend's address within your Fastly service's configuration. This allows your origin server to be configured with the same domain as your Fastly service.

Loop detection can also be triggered if the backend for one Fastly service is another Fastly service. Doing this intentionally is called service chaining, but it may also happen unintentionally if your service uses a backend operated by a third party that happens to also be a Fastly customer.

A request will be rejected as a loop if it exceeds one of these limits:

• at most 3 prior visits to this POP on behalf of this Fastly service
• at most 6 prior unique Fastly services executed by the request
• at most 20 total prior hops, where a hop is defined as a handoff from one Fastly service to another

Although loop detected errors are triggered before your service code is invoked, the response will be returned to the parent instance of your service code, where it can be handled in VCL services by reading bresp.status and beresp.response in vcl_fetch or in a Compute program by examining the status and reason text exposed by the Response object.

GET and HEAD requests with body

The IETF’s HTTP specifications (notably RFC-9110, though there are others) do not specify, in most cases, the behavior of GET or HEAD requests that contain an HTTP body. To maintain the best possible security posture for our customers, Fastly denies these requests by default and notifies customers of these denied requests by incrementing request_denied_get_head_body (part of our historical stats API). Should you have a specific need to send GET or HEAD requests with bodies, contact Support to discuss the security implications in more detail.