---
title: "Varnish Server-Timing (Help Center / Settings / Server-timing)"
ai_context: "Use this article for questions about Varnish Server-Timing, cache diagnostics, cache HIT/MISS/PASS status and combining Varnish cache information with origin timing in RUMvision. It covers adding `Server-Timing` through VCL, using `vcl_hit`, `vcl_miss`, `vcl_pass` and `vcl_deliver`, exposing `varnish_cache`, preserving existing origin `Server-Timing` values and appending Varnish cache status instead of replacing backend timings. Relevant for questions about Varnish caching, origin latency, TTFB investigation, HTML document requests, VCL configuration, DevTools validation, `PerformanceServerTiming`, staging validation and setups where NGINX, Apache or the application emits `origin;dur=...` before Varnish handles the response."
canonical: "https://www.rumvision.com/help-center/settings/server-timing/varnish/"
---

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) > Varnish

# Varnish Server-Timing

RUMvision can collect Varnish timing and cache data when your website exposes it through the `Server-Timing` response header.

This helps you understand whether slow server response times are related to Varnish cache behavior or to your origin server.

Varnish does not expose standard Server-Timing metrics by default. If your site is not exposing these headers yet, you can add cache information in VCL and preserve origin timings sent by your origin or reverse proxy.

## Add Server-Timing via Varnish

### Recommended fields

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

    Value Type/source Meaning     `varnish_cache` **Filter**  
 VCL cache handling Shows whether Varnish handled the request as `HIT`, `MISS`, or `PASS`.   `origin` *not collected*  
 implement yourselves Time spent at the origin.  
 This should be emitted by your application, NGINX, Apache, or another origin layer before Varnish receives the response.   

### Where to implement

Implement this in your Varnish VCL configuration.

 ```
/etc/varnish/default.vcl
```

### Rule to implement

Apply this 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:

```
sub vcl_hit {
  set req.http.X-RUM-Varnish-Cache = "HIT";
}
sub vcl_miss {
  set req.http.X-RUM-Varnish-Cache = "MISS";
}
sub vcl_pass {
  set req.http.X-RUM-Varnish-Cache = "PASS";
}

sub vcl_deliver {
  if (!req.http.X-RUM-Varnish-Cache) {
    set req.http.X-RUM-Varnish-Cache = "UNKNOWN";
  }

  if (resp.http.Server-Timing) {
    # Append to existing Server-Timing
    set resp.http.Server-Timing = resp.http.Server-Timing + ", varnish_cache;desc=" + req.http.X-RUM-Varnish-Cache;
  } else {
    # Set Server-Timing http header
    set resp.http.Server-Timing = "varnish_cache;desc=" + req.http.X-RUM-Varnish-Cache;
  }

  unset req.http.X-RUM-Varnish-Cache;
}
```

This adds Varnish cache information to `Server-Timing`. If your origin already emits an `origin` timing, this configuration keeps it and appends the Varnish cache status.

## 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: origin;dur=248, varnishCache;desc=MISS
```

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

 ```
Server-Timing: varnishCache;desc=HIT
```

### 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.
 
### Varnish notes

This VCL only adds `varnishCache` to the `Server-Timing` header. It does not calculate or add origin timing itself.

If you also want `origin;dur=...`, your origin application, NGINX, Apache, or another backend layer must emit a Server-Timing header before the response reaches Varnish. Varnish will then preserve that existing value and append varnishCache.

If your origin already sends a `Server-Timing` header, make sure your Varnish configuration preserves it and appends its own cache information instead of replacing it.