You are reading Edgio Applications v6 docs. Check out our latest docs for Edgio Applications v7.


Each request for your content will generate a response from a server. This response consists of:

Protocol and Version

Identifies the network protocol and version (e.g., HTTP/1.1) used to transmit the response to the client. This protocol and version typically matches the one defined in the request. If an invalid protocol or version was requested, then the response will return a 505 HTTP Version Not Supported.

Status Codes

HTTP status codes are how the web signals errors and other states from the server to the web browser. If there is an error from your backend website, the error is simply forwarded by Edgio to the browser.

Edgio exclusive status codes

If the error is generated in Edgio itself, the platform generates a 53x or 54x HTTP status code:
530Internal Edgio ErrorUnexpected error in Edgio. Please contact support immediately.
531Project Upstream Connection ErrorYour project failed to establish an upstream connection. This is different from 536 where your project timed out waiting for a response from the upstream. Common causes are the upstream host you specified in your project is incorrect, the DNS entry you defined points to the wrong server, your servers are not responding, or you need to add the Edgio IP addresses to your allowlist. (Contact your operations team and ask them to add the IP addresses in Allowlisting to your server’s IP allowlist.)
532Project Response Too LargeYour project returned a response size greater than the allowed 6MB.
533Project Upstream TLS ErrorThe was an error negotiating a secure TLS connection with the upstream. Common causes are the host name provided does not match the name in the upstream TLS certificate, or the upstream TLS certificate has expired.
534Project ErrorYour project’s serverless code has failed unexpectedly or has issued a malformed response. Use server logs to debug.
535Unknown ProjectThe HTTP header host is missing or does not match any Edgio deployment. Check your requesting URL and your project config.
536Project HTTP Response TimeoutEdgio did not receive an HTTP response from the upstream. Common causes are the upstream dropped the connection prematurely, the upstream application threw an exception, and the upstream took too long to respond.
537Project DNS Resolution ErrorFailed to resolve the host name through DNS, which might indicate a problem with your DNS provider or incorrectly configured domain name.
538Project Request LoopThe Edgio project exceeded the maximum level (3) of nested Edgio requests. “Nested” means an Edgio site is the upstream of itself or of another Edgio site.
539Project TimeoutThe 539 status code is primarily caused by timeouts, but can also be caused by lack of allow lists (white lists) configured on your backend server. Timeouts: Your project’s serverless code did not respond on time, either due to slow or blocking upstream or to badly handled asynchronous requests in code (e.g. missing await or call to callback). Troubleshooting: You can view the timings and status codes of the components in the stack in the x-0-t header Use server logs and performance profiling to debug. You can also debug using information in Troubleshooting 539 Status Codes, which includes information about detecting allow list errors.
540Out of MemoryYour project’s serverless code caused an out-of-memory situation. Use server logs to debug and lower the memory use.
541Edgio Out of WorkersThe traffic was so high that the request could not be scheduled for processing within the scheduling timeout. Please contact support to upgrade your account.
542Project Header OverflowThe Edgio project’s request or response had too many HTTP headers. See limits
543Global Upstream TimeoutThe request failed to propagate between Edgio edge and the global POP. Please contact support.
544Invalid Host HeaderThe Edgio received a value in host header that is not a valid domain name.
545Edgio Component Not ReadyAn unprepared Edgio component received traffic. Please contact support immediately.
546Edgio Global POP TLS ErrorThe was an error negotiating a secure TLS connection with the Edgio global POP. Please contact support immediately.
547Edgio Global POP No HTTP ResponseEdgio did not receive an HTTP response from the global POP. Please contact support immediately.
548Edgio Global POP DNS Resolution ErrorEdgio failed to resolve the global POP’s host name through DNS. Please contact support immediately.
Obviously, your project can set status codes of their own, which may sometimes match codes above. We encourage you to avoid setting your own status code so as to lower troubleshooting overhead and other issues.

Standard status codes used by Edgio itself

Edgio also issues these standard response codes:
400Bad RequestThe URL is too long or the request headers are too large. See limits
404Not FoundThe server cannot find the requested resource. This usually occurs when the browser requests a page that your app does not have. A 404 will also occur when a request does not match any of the routes in your Edgio router. See routing for more information.
412Precondition FailedThis code is returned when the query string parameter edgio_prefetch equals 1 and the content was not found in the edge cache.

Reserved Response Headers

The x-0-* headers namespace is reserved for Edgio internal use and setting them yourself, except where so noted, is unsupported. See Prohibited Headers for more information.
  • x-0-caching-status: Indicates cache status information. If the response was not cached or served from cache, then it will report the reason why it was not cached.
    The following sample response header indicates that caching was explictly disabled for this request:
    x-0-caching-status: disabled
Learn more.
  • x-0-components: Indicates the version for each POP component that processed the request and the environment ID. This response header is primarily meant for internal use when troubleshooting issues.
  • x-0-hit-request-id: If the response is served from cache, this header indicates the unique ID of the request whose response was cached.
  • x-0-request-id: Indicates the request’s unique ID.
  • x-0-status: Contains a comma-delimited list of HTTP status codes for each POP component that processed the request.
  • x-0-surrogate-key: Contains a space-delimited list of surrogate keys (cache tags).
    Learn more.
  • x-0-t: Contains time measurements for each Edgio component through which a request was routed. It also provides cache status information for edge and global POPs.
  • x-0-version: Describes the Edgio deployment.

x-0-status Response Header

The x-0-status response header contains an HTTP status code for each POP component that processed the request. This comma-delimited list is presented sequentially according to the order in which POP components processed the request.
Syntax: x-0-status: <POP Component 1>=<Status Code 1>[,<POP Component 2>=<Status Code 2>,<POP Component n>=<Status Code n>]
A POP component is identified through the following two abbreviations:

x-0-t Response Header

The x-0-t response header contains time measurements for each Edgio POP component through which a request was routed. It also provides cache status information for edge and global POPs. This data is presented sequentially according to the order in which POP components processed the request.
Learn how Edgio routes requests.
x-0-t: <Metric 1>=<Value 1>[,<Metric 2>=<Value 2>,<Metric n>=<Value n>]
Each metric is defined through a set of abbreviations. These abbreviations identify:
  • Who handled the request:
    • e: Edge POP
    • g: Global POP
    If a global POP is the closest POP to the client, then it will act as both an edge and global POP. However, it will be assigned the e abbrevation instead of g.
    For example, you may typically measure an origin server’s response time through gdf (Global POP’s DPS Fetch Time). However, if a global POP is the closest POP to the client, then you should use edf instead since Edgio will not return gdf.
    • p: Serverless Compute (load balancer)
    • w: Serverless Compute (worker)
  • The POP component that processed the request:
    • d: Dynamic Proxy Service (DPS)
    • b: Billing
    • k: Kolben
  • The type of metric being measured:
    • c: This abbreviation represents either of the following metrics:
      • Cache status. Valid values are:
        • hit: The response was served from cache.
        • miss: The response was forwarded to the next hop in the route because a cached response with a valid time-to-live (TTL) was not found. This value, which may only be returned when cached or pass is inapplicable, typically indicates that the response contains a set-cookie header or its status code is 4xx or higher.
        • cached: The response was cached as a result of this request.
        • pass: The route corresponding to this request or cache-specific response headers prohibit caching.
        For example, gcc=miss identifies a cache miss on a global POP. A global POP forwards requests that result in cache misses to either an origin server or Serverless Compute.
      • Request count.
        For example, pc=1 indicates the number of requests generated by the Serverless Compute (load balancer). A value greater than 1 indicates that the load balancer had to scale the request by adding it to a queue and then resubmitting it. Another example is wc=19 which indicates that a Serverless Compute (worker) was invoked 19 times by this request.
    • d: DNS lookup time in milliseconds.
      DPS uses DNS caching to accelerate requests. This means that DPS may frequently report a DNS lookup time of 0.
      For example, edd identifies the DNS lookup time as measured by an edge POP’s DPS.
    • f: Fetch time in milliseconds. This metric measures the amount of time between when a POP component forwards a request and when it receives a response.
      For example, gdf indicates the amount of time between when a global POP’s DPS forwarded a request to an origin server or Serverless Compute and when it started receiving a response.
    • g: Age in seconds.
      For example, wg=746940 indicates that the instance of the Serverless Compute (worker) that processed the request has been running for approximately 747 seconds.
    • l: Sum of time in milliseconds.
      For example, wl=30896 indicates the total processing time for all Serverless Compute (workers) for all requests is 30.8 seconds.
    • m: Memory usage in Megabytes.
      For example, wm=317 indicates that Serverless Compute (worker) used 317 Megabytes of memory for this request.
    • r: Route evaluation in milliseconds.
      For example, wr=1 indicates that Serverless Compute (worker) spent 1 millisecond evaluating the route through which this request will be processed.
    • t: Total time in milliseconds. This metric measures the amount of time between the moment when the request was received to when a response was sent to the client.
      For example, wbt indicates billed time as measured by a Serverless Compute load balancer. This measurement includes Serverless Compute workload time and time spent capturing Serverless Compute log data.
    • u: Upstream fetch time in milliseconds.
      For example, pu identifies the total time between when a Serverless Compute load balancer submitted a request defined within your application’s code (e.g., fetch) and when it received a response.
    • cw: Wait in the request coalescing queue.
      For example, ecwt identifies the total time the request spent waiting in the request coalescing queue on the edge POP. The analogue for the global POP is gcwt. These are useful to check when apparent cache hits have high total time. Those cases are actually due to request coalescing resulting in a cache hit.


Most metrics follow the above convention. However, there are some metrics that use a different convention. Here are a few common exceptions to the above convention:
  • dgpop: Identifies the global POP to which an edge POP forwarded a request.
  • wa: Indicates the transformRequest time, in milliseconds, as measured by a Serverless Compute (worker).
  • wp: Indicates the fetch or proxy time, in milliseconds, as measured by a Serverless Compute (worker).
  • wz: Indicates either:
    • transformResponse: If the route uses transformResponse, then this metric measures the transformResponse time in milliseconds.
    • Image Optimization: If the route contains an image optimization tag, such as Next Image or Nuxt nuxt-img, instead of transformResponse, then this metric measures processing time in milliseconds.

x-0-version Response Header

The x-0-version response header describes the latest Edgio deployment using the following syntax:
x-0-version: <Deployment Number> <Package Version> <Environment Version> <Deployment Timestamp> <Compiler Version>
Definitions for the above variables are provided below.
  • <Deployment Number>: Identifies a deployment by its version number.
  • <Package Version>: Indicates the Edgio package version.
  • <Environment Version>: Identifies an environment by its version number.
  • <Deployment Timestamp>: Indicates the date and time (UTC; 24-hour clock) at which your site was deployed.
    Syntax: YYYY-MM-DDThh:mm:ss.msZ
  • <Compiler Version>: Indicates the Edgio compiler version through which your site was compiled.
x-0-version: 23 4.17.1 3 2022-09-15T12:54:14.721Z 1.5.0

Server Timing Response Header

Edgio adds the following values to the standard server-timing response header:
  • edgio-cache: <Cache Status>: Valid cache statuses are:
    • HIT-L1: Indicates that the request was served from an edge POP’s cache.
    • HIT-L2: Indicates that the request was served from a global POP’s cache.
    • MISS: Indicates that the request was not served from cache.
  • country: <Country Code>: Indicates the two-letter code for the country from which the request was sent.
  • xrj: <Route>: Indicates the route that Edgio mapped to the request. This route is serialized into JSON.

Serverless Compute - Cold Start Timing

To calculate the Serverless cold start timing you must take the difference between pf and wt in the x-0-t header. wt is time taken for the Serverless Compute worker to execute after it has started, this is can be read as the time is takes the project code to execute. If that seems large, evaluate the code within your project to see why this might be. To track timings for a function, it is possible to add specific code to do that.
Based on the example above, that would be 809 (pf) - 722 (wt) = 87ms.

Response Body

Contains the data provided in response to the request.
For example, the response body for a GET request for a text file might look similar to the following:
1Hello World!