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.
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.
The format is
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)
Component names within the header are abbreviated:
|eh||HAProxy on edge POP|
|ec||Varnish cache on edge POP|
|ed||DPS on edge POP|
|gh||HAProxy on global POP|
|gc||Varnish cache on global POP|
|gd||DPS on global POP|
|p||Serverless Load Balancer|
|t||Total time (example: |
|f||Fetch time (example: |
|c||Cache status (example: |
|bt||Billed time (example: |
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:
|Edge POP total time of 1160ms|
|Edge POP Varnish total time of 1158ms|
|Edge POP Cache Miss, on miss the request will go to global POP|
|Edge POP DPS total time of 1015ms|
|Edge DPS DNS lookup time of 0ms (We do DNS caching in DPS to accerate requests, so 0 is common and expected)|
|Edge DPS Fetch time of 1152ms|
|Global POP HAProxy total time of 869ms|
|Global POP Varnish total time of 866ms|
|Global POP Cache Miss - on miss request will go to backend|
|Global POP DPS total time of 853ms|
|Global POP DNS Lookup time of 0ms (implying cached DNS lookup)|
|Global POP DPS fetch time to backend of 853ms|
|Serverless Load Balancer Total time of 811ms|
|Serverless Load Balancer total request count. if > 1 it implies scaling where we had to queue and retry this request|
|Serverless Load Balancer Total Fetch time to serverless of 809ms|
|Serverless billed time of 723ms. This includes serverless workload time plus time spent capturing serverless logs.|
|Serverless worker memory used 317mb|
|Serverless workload time of 722ms|
|Number of times this specific serverless instance has been invoked (19)|
|Age of this serverless instance of 749s|
|Sum of worker times across all requests of 30.8s|
|Time spent evaluating route of 1ms|
|Worker fetch or proxy time of 705ms|
|If the route is using |
x-0-status header will show the response codes received from the preceding service at each step in the process
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
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.
To calculate the Serverless cold start timing you must take the difference between
wt in the
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.
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