Response Headers

This guide describes the headers that Layer0 injects into responses, making them visible to your client code. Note that the x-0-* headers namespace is reserved for Layer0 internal use and setting them yourself, except where so noted, is unsupported.

General Headers

  • x-0-version: version fingerprint that includes Layer0 version number, site build number and UTC timestamp of the build
  • x-0-t: telemetry measurements for all the components in Layer0 critical path that served your request
  • x-0-request-id: the unique ID of the request on Layer0 infrastructure
  • x-0-hit-request-id: the unique ID of the request whose cached response is being returned (not present if cache miss)
  • x-0-caching-status: indicates why a response was or was not cached. See Caching.
  • x-0-surrogate-key: a space separated list of secondary cache keys used for cache clearing that can be injected when needed into your backend responses.

Structure of x-0-t

The format is x-0-t: <id>=<time>[,<id2>=<time2>...]

x-0-t is an ordered list of telemetry measurements; values are prepended at response time. Thus, from left to right, measurements are ordered from the outermost edge component to the innermost cloud component that handled the request.

All times are in milliseconds.

The following structure is important to note when reading the telemtry data:

All POPs have the same components:

  • HAProxy -> Varnish -> DPS
  • L1 is Edge w/ HAProxy -> Varnish -> DPS -> Global POP
  • L2 is Global w/ HAProxy -> Varnish -> DPS -> backend (user defined backend from layer0.config | static page | Serverless Load Balancer->Serverless)
When a request is reentrant, telemetry information is not duplicated; instead, each request logs its own telemetry but does not return it to the downstream Layer0 request. As a result, duplicate entries are not possible.

Component Names and Prefixes

Component names within the header are abbreviated:

AbbreviationComponent Name
ehHAProxy on edge POP
ecVarnish cache on edge POP
edDPS on edge POP
ghHAProxy on global POP
gcVarnish cache on global POP
gdDPS on global POP
pServerless Load Balancer
wLambda workers

Telemetry Types

tTotal time (example: eht) total time as measured by edge HAProxy)
fFetch time (example: gdf) total fetch time time as measured by global DPS)
cCache status (example: ecc=miss,...,gcc=hit) miss on the edge pop, hit on the global pop
btBilled time (example: wbt) serverless billed time as measured by serverless load balancer)


The examples below use a response that traversed from the edge, to global and to serverless:



Below is a translation of each value in this example:

eh=1160Edge POP total time of 1160ms
ect=1158Edge POP Varnish total time of 1158ms
ecc=missEdge POP Cache Miss, on miss the request will go to global POP
edt=1152Edge POP DPS total time of 1015ms
edd=0Edge DPS DNS lookup time of 0ms (We do DNS caching in DPS to accerate requests, so 0 is common and expected)
edf=1152Edge DPS Fetch time of 1152ms
gh=869Global POP HAProxy total time of 869ms
gct=866Global POP Varnish total time of 866ms
gcc=missGlobal POP Cache Miss - on miss request will go to backend
gdt=853Global POP DPS total time of 853ms
gdd=0Global POP DNS Lookup time of 0ms (implying cached DNS lookup)
gdf=853Global POP DPS fetch time to backend of 853ms
pt=811Serverless Load Balancer Total time of 811ms
pc=1Serverless Load Balancer total request count. if > 1 it implies scaling where we had to queue and retry this request
pf=809Serverless Load Balancer Total Fetch time to serverless of 809ms
wbt=723Serverless billed time of 723ms. This includes serverless workload time plus time spent capturing serverless logs.
wm=317Serverless worker memory used 317mb
wt=722Serverless workload time of 722ms
wc=19Number of times this specific serverless instance has been invoked (19)
wg=746940Age of this serverless instance of 749s
wl=30896Sum of worker times across all requests of 30.8s
wr=1Time spent evaluating route of 1ms
wp=705Worker fetch or proxy time of 705ms
wa=1transformRequest time
wz=1If the route is using transformResponse, this is the transformResponse time in ms. If the route does not contain a transform, but contains an image optimization tag, like Next Image or Nuxt nuxt-img this is that processing time

The x-0-status header will show the response codes received from the preceding service at each step in the process x-0-status: eh=200,ed=200,gh=200,gd=200,p=200,w=200


x-0-components. This is most useful for Layer0 in identifying the versions of each service, the id of the environment, and which backend serviced the request

x-0-components: eh=0.1.6,e=atl,ec=1.1.0,ed=1.0.1,gh=0.1.6,g=hef,gd=1.0.1,p=1.21.10,w=3.11.0,wi=e8ce8753-163d-4be9-a39e-40454ace5146,b=serverless

Server Timing

Layer0 adds the following values to the standard server-timing response header:

  • layer0-cache: desc=value - value will be one of:
    • HIT-L1 - The page was served from the edge cache
    • HIT-L2 - The page was served from the shield cache
    • MISS - The page could not be served from the cache
  • country: desc=country_code - where country_code is the two letter code of the country from which the request was sent.
  • xrj: desc=route - where route is the matched route serialized as JSON.

Serverless Timing

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 lambda 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.

Troubleshooting Headers

The following headers are used internally by Layer0 staff to troubleshoot issues with requests.

  • x-0-status: HTTP status that each component in Layer0 returned (can vary depending on the component)
  • x-0-components: version of various components in Layer0 critical path that serviced your request