Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

[synthetics] timing break down meaning



I’m looking for help with understanding meaning of metrics.

In NR Synthetics, simple ping check, the timing is broken down to:
DNS lookup
SSL negotiation

While DNS lookup, SSL negotiation, and Connecting meaning seem clear to me, it’s not so much for other phases. For example, does “Sending” mean sending the request from NR machine to my server, or does it mean my server sending the response? What is “Receiving”? I can see it takes only microseconds, so what is it? It’s using HEAD method, so not fetching body, but still microseconds sound not very realistic to me.

Any help / hint is much appreciated, thanks


Hi there @pawel_rein, all those are timings captured in our synthetics job runners talking to your server. Sending is the time it took to send the HTTP request to your server and “receiving” is the time it took to read the response. Waiting is the time in took between sending and receiving. You can find a detailed description of all those timings in the HAR spec here:

All timings are in milli seconds, did you see micro seconds displayed anywhere?


Hi rferreira,

Thanks for your reply and for linking the docs.
As for microseconds, please see attached screenshot.



oh wow that’s a bug, we’ll fix it right away.


@pawel_rein I might have spoken too soon, can I have a link to this monitor so I can research it some more?


Sure, there you go:



Hi there @pawel_rein I have an explanation for you, the short version is, those numbers are indeed correct. Our Ping monitors first try a HEAD request and a subsequent GET (if the head fails). Because your endpoints are responding just fine to the HEAD requests as you can see here:

the receiving time is very close to 0 (since there’s no body to receive just a small response header) but not quite zero (hence the micro second times). In the individual result view (the link I sent above) we round everything to msec or greater so it shows up as simply 0.

Let me know if that makes sense,

  • Rafael


Hi @rferreira. Thanks for further investigation.

There’s still something I don’t understand. Perhaps you can help me with that. Why “sending” takes so much more time than “receiving”? Per definition “sending” is “Time required to send HTTP request to the server.” It doesn’t include waiting for response, which has it’s own metric. It’s just about the same as receiving the headers in response, just the other direction, correct? Why it takes so much longer then?

And one more thing, more like feature request. I find measuring response time to HEAD request of little meaning as compared to (more real life) measuring response time to GET request. It would be cool to be able to switch from HEAD to GET method in check configuration.



Sending is primarily impacted by the payload size, distance and by your ability to receive the traffic. The HEAD/GET behavior is in part for legacy reasons (we’re copying the behavior from the current availability monitor) but we do intend to make it configurable.

Let me know if this helps!


Thanks, it helped.
PS. I think I’m gonna pay less attention to synthetics till NR introduces configurable GET requests.


Hi there!

I just wanted to let everyone know that Ping monitors can now be configured to only perform GET requests:

  • The Bypass HEAD request option is available for ping. This option skips the default HEAD request and instead uses the GET verb with a ping check.