---
title: "Fastly Server-Timing (Help Center / Settings / Server-timing)"
ai_context: "Use this article for questions about Fastly Server-Timing, CDN delivery diagnostics, cache behavior, edge processing, origin latency and exposing Fastly timing data to RUMvision. It covers adding `Server-Timing` through VCL or Fastly Compute, recommended fields such as `processing`, `cdn-cache`, `cdn-pop` and `cdn-region`, configuring `vcl_deliver`, preserving origin or application timings on cache misses, and overwriting stale cached timings on cache hits. Relevant for questions about Fastly HIT/MISS status, POP and region information, delivery latency, TTFB investigation, VCL snippets, `time.elapsed.msec`, `server.pop`, `server.region`, DevTools validation, `PerformanceServerTiming`, RUMvision tech stack integration, staging validation and preserving existing origin `Server-Timing` headers."
canonical: "https://www.rumvision.com/help-center/settings/server-timing/fastly/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > [Help Center](https://www.rumvision.com/help-center/?format=md) > [Settings](https://www.rumvision.com/help-center/settings/?format=md) > [Server-timing](https://www.rumvision.com/help-center/settings/server-timing/?format=md) > Fastly

# Fastly Server-Timing

RUMvision can collect Fastly timing data when your website exposes it through the [`Server-Timing` response header](https://www.rumvision.com/help-center/monitoring/settings/custom-performance-timing/?format=md#server-timing).

This helps you understand whether slow server response times are caused by Fastly delivery, edge compute, the origin server, or cache behavior.

If your site is not exposing these headers yet, you can add them in Fastly with VCL or from your Fastly Compute application.

## Add Server-Timing via Fastly

### Recommended fields

Below are the recommended fields to expose. Once these fields are exposed and Fastly is selected as the CDN in your [tech stack settings](https://www.rumvision.com/help-center/monitoring/settings/domain-settings/?format=md#tech-stack) and enabled the Fastly checkbox, we will automatically collect them.

    Value Type/Source Meaning     `processing` **Metric**  
 [time.elapsed.msec](https://www.fastly.com/documentation/reference/vcl/variables/client-request/time-elapsed-msec/) Time spent in the Fastly Delivery layer for this request.  
 Shows the time since the request started in milliseconds.   `cdn_cache` **Filter**  
 [`X-Cache`](https://www.fastly.com/documentation/reference/http/http-headers/X-Cache/) Shows whether the response was served from cache.  
 For example `HIT` or `MISS`.   `cdn_colo` **Filter**  
 [`server.pop`](https://www.fastly.com/documentation/reference/vcl/variables/server/server-pop/) An identifier representing one of [Fastly's POP locations](https://www.fastly.com/documentation/guides/concepts/pop/).  
 This is the POP where the VCL code is currently running.   `cdn_region` **Filter**  
 [`server.region`](https://www.fastly.com/documentation/reference/vcl/variables/server/server-region/) A code representing the general region of the world in which the POP location resides.  
 For example `SA-East` for Eastern South America or `APAC` for Australia and New Zealand   

### Where to implement

In Fastly, go to:

- `Fastly`
- `Select service`
- `Edit configuration`
- `Clone active version`
- `VCL snippets`
 
Add the Server-Timing logic in `vcl_deliver`.

### Rule to implement

Create a VCL snippet and apply it to all HTML document requests. These are the main page requests RUMvision uses to understand document TTFB and backend-related delays.

This usually means the main document request of your pages, not images, scripts, stylesheets, or API calls.

If needed, you can also expose these timings on other request types, but HTML document requests are the recommended starting point.

Add the following VCL snippet (code from [Fastly blog](https://www.fastly.com/blog/lightweight-latency-measurement-with-server-timing))

```
sub vcl_deliver {
  if ( fastly.ff.visits_this_service == 0 ) { 
    # Any Server-Timing header is cached and old, so overwrite  
    if ( resp.http.X-Cache ~ "HIT") { 
      set resp.http.Server-Timing = "processing;dur=" + time.elapsed.msec
        + ", cdn-cache;desc=HIT"
        + ", cdn-pop;desc=" + server.pop
        + ", cdn-region;desc=" + server.region;
    } else { 
      # Communicated with origin, so append if present
      if ( resp.http.Server-Timing ) { 
        add resp.http.Server-Timing = "processing;dur=" + time.elapsed.msec; 
      } else { 
        set resp.http.Server-Timing = "processing;dur=" + time.elapsed.msec; 
      } 
      
      add resp.http.Server-Timing = "cdn-cache;desc=MISS";
      add resp.http.Server-Timing = "cdn-pop;desc=" + server.pop;
      add resp.http.Server-Timing = "cdn-region;desc=" + server.region;
    } 
  } 
}
```

If your origin or Fastly Compute application already emits `origin` or `compute` timings, this VCL keeps those values on cache misses and adds the Fastly delivery timing.

## Testing the outcome

Next step is testing the outcome. You could either wait for data to arrive in your RUMvision dashboard, or proactively test the outcome using the DevTools of your preferred browser.

### Expected outcome

For a cache miss where the origin also exposes timing data, your HTML document may return a header similar to this:

 ```
Server-Timing: delivery;dur=1, fastlyCache;desc=HIT, fastlyPop;desc=AMS;fastlyRegion;desc=EU-West
```

For a cached response, the header may look like this:

 ```
Server-Timing: origin;dur=248, delivery;dur=25, fastlyCache;desc=MISS, fastlyPop;desc=AMS;desc=EU-West
```

### Check the response headers

To verify the setup:

1. Open your website in Chrome or Edge.
2. Open DevTools.
3. Go to the Network tab.
4. Reload the page.
5. Click the main HTML document request.
6. Check the Response Headers section.
7. Look for `server-timing`.
 
### Test in DevTools Console

As the browser exposes `Server-Timing` values through the `PerformanceServerTiming` interface, you can also test it in the browser console by running the following JavaScript:

```
const navEntries = window.performance.getEntriesByType('navigation');
console.table( navEntries[0].serverTiming );
```

## Important

In general, be sure to:

- Always test on staging environment before deploying these steps to a production environment.
- Avoid exposing sensitive internal details. `Server-Timing` data is visible in the browser, so only expose metrics that are safe to share with visitors and third-party scripts.
 
### Fastly notes

If your origin already sends a `Server-Timing` header, make sure your Fastly VCL preserves it on cache misses. Otherwise, useful origin or application metrics may be removed.

On cache hits, origin timings from a previously cached response may be stale. That is why this example overwrites Server-Timing on cache hits and only exposes Fastly delivery and cache status.