1. Home
2. Reference documentation
3. Compute

This guide serves as a comprehensive reference for error events that can occur within a Fastly Compute service. Understanding these events helps with troubleshooting and maintaining the reliability of your service.

The diagnostic log output described in this document is designed for troubleshooting and visibility. Because this output may change over time as diagnostics improve, use the HTTP status codes returned in the response for automated error handling and application logic.

Sandbox Resource Limits

These fatal errors occur when a Compute sandbox reaches a maximum allowed resource threshold, specifically runtime duration, vCPU usage, or heap memory limits. Reaching these limits terminates the sandbox immediately, typically returning an HTTP 500 or 503 to the client. Each specific error event type has its own dedicated metric, and all of these events contribute to the overall categorical metric compute_service_resource_limits_error.

Sandbox Timeout

The sandbox reached the maximum wall-clock runtime limit. This event increments the compute_service_resource_limits_error and compute_service_timeout_error metrics.

Returns HTTP 503 with the following diagnostic metadata:

{"diagnostic": "instance_limit", "limit": "timeout"}

Troubleshooting: Optimize long-running loops or complex logic. Ensure origin response times are within the configured timeout thresholds, as the sandbox remains active while waiting for I/O.

Memory Exceeded

The sandbox consumed the maximum memory (heap) allocated by the platform. This event increments the compute_service_resource_limits_error and compute_service_memory_exceeded_error metrics.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "instance_error", "error": "heap_exhausted", "trap": {"trap_code": $CODE, "display_reason": "$REASON"}}

Troubleshooting: Check for memory leaks or large object allocations. Use streaming APIs for request and response bodies rather than buffering entire payloads into memory.

vCPU Limit

The sandbox exceeded the maximum active processing (vCPU) time. This event increments the compute_service_resource_limits_error and compute_service_vcpu_exceeded_error metrics.

Returns HTTP 503 with the following diagnostic metadata:

{"diagnostic": "instance_limit", "limit": "cpu_timeout"}

Troubleshooting: Reduce compute-intensive tasks such as heavy cryptography, image manipulation, or complex data transformations. Profile your code to identify and optimize CPU-heavy functions.

Runtime and Logic Errors

These errors are triggered during service code execution and request routing. They range from fatal crashes caused by invalid code behavior to non-fatal threshold violations that your service code can catch and handle. Each subcategory tracks a different stage of execution: runtime errors occur within your WebAssembly code, service chain errors involve request routing between services, service limits are recoverable threshold violations, and backend request errors occur when communicating with your origins.

Runtime Errors

These fatal errors occur during service code execution due to WebAssembly (Wasm) traps, invalid service logic, or prohibited actions. These events increment the compute_service_runtime_error metric.

Stack Overflow

The service code exceeded the maximum call stack size.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "instance_error", "error": "stack_overflow", "trap": {"trap_code": $CODE, "display_reason": "$REASON"}}

Troubleshooting: Review your code for deep or infinite recursion. Ensure recursive functions have a guaranteed exit condition.

Unreachable Code

The sandbox encountered a logical trap or an "unreachable" instruction, often inserted by the compiler.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "instance_error", "error": "entered_unreachable", "trap": {"trap_code": $CODE, "display_reason": "$REASON"}}

Troubleshooting: This is often caused by language-specific panics (e.g., panic! in Rust) or assertion failures. Check your service logs for stack traces or error messages emitted before the crash.

Multiple Responses Sent

The sandbox attempted to send more than one HTTP response for a single request.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "multiple_results_sent"}

Troubleshooting: Ensure that your code only calls response-sending functions once per request. Use control flow to prevent multiple execution paths from sending responses.

Sandbox Memory Fault

The sandbox attempted to access memory outside its allocated bounds.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "instance_error", "error": "heap_out_of_bounds", "trap": {"trap_code": $CODE, "display_reason": "$REASON"}}

Troubleshooting: This is common when using lower-level languages like C++ or Rust with unsafe blocks. Verify pointer arithmetic and ensure you are not dereferencing null or out-of-bounds pointers.

Invalid Memory Access

The service attempted to make an invalid communication with the Compute platform. This error occurs when a sandbox attempts a low-level hostcall using invalid arguments, such as a misaligned pointer. Because these low-level operations are automatically managed by the official Fastly SDKs, this error is rare under normal conditions.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "invalid_memory_access"}

Troubleshooting: Ensure your service is using the most recent version of the Fastly SDK for your chosen language. Improvements and bug fixes in memory management are frequently included in SDK updates.

If you encounter this error while using the latest version of an official Fastly SDK, it likely indicates a bug in the SDK or the platform interface. Reach out to Fastly support with your service ID and relevant log output.

Attempted to Set a Prohibited Header

The service code attempted to set an HTTP header that is restricted by the platform.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "prohibited_header", "name": $NAME}

Troubleshooting: Remove logic that attempts to manually set restricted headers (e.g., Content-Length, Transfer-Encoding, or internal Fastly headers).

Sandbox Runtime Terminated

This error indicates that the service code within the Compute sandbox intentionally exited with a non-zero exit code.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "runtime_terminated", "exit_status": $STATUS}

Troubleshooting: Review your source code for explicit calls to termination functions, such as std::process::exit() in Rust or process.exit() in JavaScript, and ensure they are only used as intended. Some language runtimes or frameworks may trigger a non-zero exit code when encountering an unrecoverable internal state. Ensure your dependencies and runtime configurations are compatible with the Fastly Compute environment.

Other sandbox error

A logical error occurred in the service's WebAssembly (Wasm) code, preventing further execution. This category serves as a catchall for fatal Wasm traps that are not specifically classified as stack overflows, unreachable code, or memory faults.

Returns HTTP 500 with the following diagnostic metadata:

{"diagnostic": "instance_error", "error": "other_trap", "trap": {"trap_code": $CODE, "display_reason": "$REASON"}}

Troubleshooting: The $REASON field in the log output provides a string representation of the specific error. Use this to identify the exact nature of the trap.

Also, check for mathematical errors in your code. Common causes include integer division by zero or integer overflow. Ensure your logic validates inputs before performing arithmetic operations.

Verify that your code is not attempting to access array elements or data structures outside of their defined boundaries.

Service Chain Errors

These errors occur when a request exceeds limits related to service chaining or circular dependencies. These increment the compute_service_chain_error metric.

CDN-Loop Max Hops

The request was terminated because it exceeded the maximum allowed number of hops between services.

Returns HTTP 503 with the following diagnostic metadata:

{"diagnostic": "service_chain_error", "error": {"maximum_hops_exceeded": {"limit": "$LIMIT"}}}

Troubleshooting: Check your service configuration for deep chaining. Ensure that requests are not unintentionally looping back through multiple Fastly services.

CDN-Loop Max Services

The request reached the maximum allowed count of unique chained services.

Returns HTTP 503 with the following diagnostic metadata:

{"diagnostic": "service_chain_error", "error": {"maximum_services_exceeded": {"limit": "$LIMIT"}}}

Troubleshooting: Reduce the number of unique Fastly services involved in processing a single request.

CDN-Loop Detected

The request was terminated because the platform detected a direct loop or an invalid service chain configuration during request forwarding. Fastly uses the CDN-Loop and Fastly-FF headers to track "hops" between services—including transitions between Wasm (Compute) and VCL services—to prevent infinite routing loops.

Returns HTTP 503 with the following diagnostic metadata:

{"diagnostic": "service_chain_error", "error": "loop_detected"}

Troubleshooting: Ensure that backend requests do not target the same service they originated from. Consider using edge-side logging to capture the values of the CDN-Loop and Fastly-FF headers. Verify your logic for handling the headers to prevent circular routing. A loop is often detected when the current Service ID appears earlier in the chain's history.

Service Limits

Service limits are non-fatal errors that occur when service code attempts an operation that exceeds a specific functional threshold. Unlike resource limits or sandbox errors, these do not terminate the sandbox or automatically return an HTTP error code to the client. Instead, the relevant SDK function will return an error result, allowing your service code to catch the exception and decide on a fallback action, such as logging the event or serving a simplified response.

These increment the compute_service_limits_error metric.

Backend Requests Limit

The sandbox reached the maximum allowable number of backend requests per execution.

Produces the following diagnostic metadata:

{"diagnostic": "instance_limit", "limit": "backend_requests"}

Troubleshooting: Reduce the number of fetch() or send() calls within a single execution. Consolidate multiple backend calls into a single request where possible.

Cache Transactions Limit

This error occurs when a sandbox performs too many individual cache operations (such as lookups, inserts, or transactions) within a single execution.

Produces the following diagnostic metadata:

{"diagnostic": "instance_limit", "limit": "cache_transactions"}

Troubleshooting: Review your code for loops that interact with the cache. Consolidate cache lookups where possible. If you are performing many small cache operations, consider batching data into a single cached object to reduce the transaction count.

Dictionary Lookups Limit

The sandbox exceeded the allowed number of Edge Dictionary lookups per execution.

Produces the following diagnostic metadata:

{"diagnostic": "instance_limit", "limit": "dictionary_lookups"}

Troubleshooting: If you need the same key multiple times, cache the result in a local variable instead of performing multiple lookups. Alternatively, Config Store supports similar functionality and is optimized for the Compute environment.

Dynamic Backends Limit

This occurs when a service has exceeded the limit on the number of dynamic backends it can use concurrently across all its active sandboxes. Dynamic backends are created programmatically at runtime rather than being predefined in your service configuration.

Unlike other limits that return an immediate error code, this operation blocks execution. The sandbox will pause and wait for a backend slot to become available (e.g., when another sandbox of the same service terminates and releases its backends).

Troubleshooting: Reuse existing dynamic backends whenever possible. If you have a predictable set of origins, define them as static backends in the Fastly control panel or via the API instead of using dynamic registration.

Cache Bytes Written Limit

This limit is triggered when the total volume of data written to the cache across all operations in a single execution exceeds the allowable threshold.

Produces the following diagnostic metadata:

{"diagnostic": "instance_limit", "limit": "cache_bytes_written"}

Troubleshooting: Monitor the size of the data your service attempts to cache. If you are caching large payloads, consider compressing the data before writing it to the cache. Alternatively, evaluate if certain large objects should be streamed directly to the client without being stored in the cache.

Cache Object Size Limit

This occurs when a single attempted cache write operation exceeds the maximum size allowed for an individual object.

Produces the following diagnostic metadata:

{"diagnostic": "instance_limit", "limit": "cache_object_size"}

Troubleshooting: Check the size of objects before calling the cache write function. If an object is too large, you may need to segment it into smaller chunks or store only critical metadata. Ensure that your service logic handles cases where an object is too large to be cached without failing the entire request.

Backend Request Errors

These are failures encountered when a Fastly Compute service attempts to communicate with a backend (origin). This count includes network-level failures, timeouts, 5xx responses from the backend and any upstream failures, including other Fastly services.

These increment the compute_service_bereq_error metric.

Troubleshooting: If requests are failing due to slow origin responses, consider increasing connection timeouts, such as the first_byte_timeout or between_bytes_timeout, in your service configuration.

Verify that your origin server is healthy and capable of providing valid responses. Ensure it has not reached its maximum concurrent connection limit.

Confirm that backend properties like override_host, ssl_sni_hostname, and ssl_cert_hostname are correctly set, especially when using hostnames instead of IP addresses.

Check stderr for descriptive output related to unhandled errors or panics that might occur before a response is generated.

Platform Errors

Platform errors occur when the Fastly infrastructure cannot initialize the execution environment or when an incoming request is rejected before it reaches your service code. These errors are generally not caused by the logic within your WebAssembly binary but may require changes to how clients or upstream systems interact with your service.

Internal Platform Error

These are internal system events indicating that the platform was unable to initialize or maintain the execution environment for your service.

These increment the compute_platform_internal_error metric.

Returns HTTP 5XX with the following diagnostic metadata:

{"diagnostic": "internal_error"}

Troubleshooting: Reach out to Fastly support to investigate potential transient infrastructure issues.

Invalid Request Errors

These errors represent malformed external requests that are rejected by the Compute platform before they can be processed by your service code. This is distinct from an "invalid request" that your service logic might receive and choose to reject; in this case, the platform itself determines the request is not processable and terminates it at the edge.

These events increment the compute_platform_invalid_request_error metric.

Unauthorized Purge

An unauthorized Fastly API purge request was made to the service.

Returns HTTP 401 with the following diagnostic metadata:

{"diagnostic": "invalid_request", "kind": "unauthorized_purge"}

Troubleshooting: This is caused by a customer-initiated request rather than the service code. Verify that purge requests include the required authentication credentials.

CDN-Loop Bad Header

A Bad Header error occurs when your service code attempts to set an HTTP header name or value that contains invalid characters or violates HTTP protocol specifications. This typically includes the presence of control characters, newlines (CRLF), or other non-permitted symbols that could lead to header injection vulnerabilities.

Returns HTTP 400 with the following diagnostic metadata:

{"diagnostic": "invalid_request", "kind": "bad_cdn_loop_header"}

Troubleshooting: Ensure that incoming requests do not contain an invalid CDN-Loop header. The header must comply with RFC 8586, typically consisting of a valid pseudonym (such as a domain name or a specific platform identifier).

Use edge-side logging to capture the exact value of the CDN-Loop header from failing requests. If the header is being sent by a client or bot with an incorrect syntax, it must be corrected at the source to pass platform validation.