[Support Guide] Netlify Support asked for the 'x-nf-request-id' header? What is it and how do I find it?

Last reviewed by Netlify Support staff August 2023

What is the x-nf-request-id header?

Web servers and web browsers communicate using a protocol called HTTP - which stands for “HyperText Transfer Protocol”. Both web browsers and web servers use a feature called headers as part of this protocol.

The headers that web browsers send are called “request headers” because the browser in making an “HTTP request”.

The web servers headers are called “response headers” because web servers send an “HTTP response”.

Netlify creates a unique HTTP response header for each request it replies to - the x-nf-request-id response header. Even if the response is a 404 (not found) or a 301 (redirect to another page, with no other content) - Netlify’s system adds this header.

Why is the x-nf-request-id header important? Why did Netlify Support ask for it?

This header, again, is unique for each individual HTTP response. Using this one header, our support team can find the exact HTTP response (and request) associated with it in our internal logs, which have many details which can help us with troubleshooting.

We could ask you for you for the following details to find the HTTP request and response:

  • the complete URL requested
  • the IP address for the system making the request
  • the IP address for the CDN node that responded
  • the day of the request
  • the time of the request
  • the timezone the time is in

Instead, we just ask for the x-nf-request-id header and we then don’t need the details above; the header alone allows us to search our logs and find the exact HTTP response (and the request which generated it).

To summarize, it is much less work (in most cases) for both the person using Netlify and our support team to ask for the x-nf-request-id instead of the list of details above.

How do I find the x-nf-request-id header?

There are many ways to see the HTTP request/response header for your HTTP requests. The simplest is probably to use your web browsers “devtools” (developer tools) to see the headers.

1. Open the developer tools for your browser

For each browser, they may be a different way to do this. As I am often using Chrome for testing, F12 will open the network tab of devtools automatically.

Links to documentation about how to open dev tools for various web browsers:

2. Click on the ‘Network’ tab

Once you have devtools open, click on the network tab of the devtools.

There won’t be any data there yet. This header information if only available for HTTP requests which occur after the devtools are opened.

3. Generate the HTTP request

Now, it is time to generate HTTP traffic with the devtools open. This can be done by navigating to the URL where are are trying to capture this header or simply by refreshing the page if you are already at the URL in question.

4. Find the header

When web pages load, there are typically many HTTP request for multiple assets. Please make sure you find the request which is of interest. This might be a particular file like “asset.png”, or it might be the base URL (https://sitename.netlify.app or https://example.com). All requests to Netlify will generate responses with this header, so make sure you’ve found the “wrong” response to get the header from.

Click on the request you are interested in and find the HTTP response (not request) headers. Each browser’s developer tools widget is slightly different, so please consult your browser’s documentation if there are questions about how to find this.

For example, in Chrome, after clicking on the request - then click on the “Headers” tab to see these headers.

5. Copy/paste (PLEASE NO SCREENSHOTS!!!) the x-nf-request-id header

Yes, I wrote “please no screenshots” in all capitals and used three escalation points. Please copy/paste the text for the x-nf-request-id.

Why copy/paste? Well, to search for your HTTP request/response, we need to enter this as text into a tool. If you send us a screenshot, we need to type this 26 character string in by hand. As these are hexadecimal strings, they are not “human readable” in a traditional sense.

Please note we will be unable to assist if we can’t copy/paste the x-nf-request-id

Now, I’m going to almost break my own rule so show what these headers look like. Yes, I’m included screenshots below. Again, though, no one is going to need to type these headers in so I’m not (technically) breaking any rules. :wink:

As always, if there are questions about this, please let us know with a comment here.





@Luke Can’t you also check this from the command line using something like this?

curl -svo /dev/null http://domain.com 2>&1 | grep 'x-nf-request-id'

Hi, @gregraven. Yes, that also will show the x-nf-request-id.

Hey @luke,

If (for example) there is an issue with a video element on the page at https://example.com, is it better (or required) that the x-nf-request-id for the video element in question is provided, or the initial page request?

If the page x-nf-request-id is provided, does Netlify then have the ability to see all the requests IDs for elements (CSS, JS, video, etc.) on that page?

Hi, @coelmay. Great question!

Ideally the x-nf-request-id value for the HTTP response that had the issue is the most useful. We are using the header to identify a problematic response in most cases so giving the header value for the exact response we are focusing on is best.

If on the other hand the initial page load x-nf-request-id value is given but not the value for the incorrect response, then our support team needs to make a best guess as to what response was the incorrect one. We might guess correctly as it could be obvious. However, even if we do guess correctly, that will still be slower than if you tell us the exact value right from the start.

To summarize, please do be specific as possible by sending us the header for the exact response that was incorrect.

1 Like

this is my x-nf-request-id 01GTEZWS11FK4F9VA08TXCXSS7

Hi @daydee , can you respond to your initial thread with this information. I’m not sure who you were talking to or what the use case was.