Check methodology - how service checks work

For HTTP check types, we use curl to issue the request and for TCP check types we open a socket. Checks are performed every 5 minutes.

Response time counting starts when we initiate the request and ends when the full response body (if any) has been returned finishing with the connection closing. This means steps like name lookup, domain resolution, opening the connection, content downloading, etc, are all included in the response time. However, we do not execute any scripts on the page, load embedded content, etc. 

A check is executed and if it returns successfully, that is the end of the cycle. If there is an error or a blank response, we queue a second verification check 10 seconds later. If this also fails then the check is considered "down".

HTTP check types will have a custom user agent string: Server Density Service Monitoring v2. There will also be a custom header named X-SD-Node which shows which monitoring node the request has come from.

Checks are executed from all selected locations in parallel which means you will get 1 request per location per check cycle. The responses may not return at exactly the same time due to latency but will generally be within a few seconds of each other. This means you get worldwide monitoring from all selected locations simultaneously, rather than in round robin.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Monday  —  Friday.

10am  —  6pm UK.

Dedicated Support.