Website monitoring
Website monitoring Website monitoring is an automated process of checking availability of a site.

Website monitoring is an automated process of checking availability of a site. The main goal of it is evaluation of possibility to access the site by clients. It is clear, that a site is efficient when an interested person can load the page and make a purchase or look for some information. If this action fails for some reason - the site does not execute its mission, and a client will find what he needs somewhere else.

There are many solutions of this problems, and all of them could be divided into passive and active ways. The result of monitoring is the value of uptime, measured with some accuracy. Having it, one can conclude how long is the site broken during some period of time (usually, for a year). Low uptime usually means that the server where the site is hosted, or internet connection to it, is unreliable and is required to be changed.

  • CM.Glossary.Uptime
  • CM.Glossary.Downtime
  • CM.Glossary.ActiveMonitoring
  • CM.Glossary.PassiveMonitoring
  • CM.Glossary.Availability
more glossary
"Thank you so much for your service. We were suspecting problems with our hosting company but they denied any problems saying the issues must be at our end. We know we do have issues at our end but still suspected that wasn't the entire story. Your service was able to prove that they are indeed going down regularly - on average twice a week during the trial period. Thanks again for providing the information we needed to make a proper decision on this issue."
- B.
Shellshock vulnerability online check

Considering the recently discovered Shellshock vulnerability, HostTracker has created a tool for testing it.

Check your server for vulnerability

How does it work?

It is developed for a Linux server with a web server installed on it. The algorithm is very simple. We consequently generate 4 http requests:

  • 1. Ordinary request
  • 2. The request tries, using vulneratility, post a "harmful" cookie which causes 2-seconds delay in respond to our special http request.
  • 3. The request tries, using vulneratility, post a "harmful" cookie which causes 4-seconds delay in respond to our special http request.
  • 4. Same as #3

How to understand the result?

We compare response time for all 4 requests. Three situation are possible:

  • 1. Vulnerability found. We may affirm that if the difference in responses is about 2 seconds for requests without cookie and with 2-second-delay cookie, as well as for requests with 2 and 4-second delay cookie. It means that our request was able to use the vulnerability and set these cookies.
  • 2. Vulnerability not found. All the requests have about the same response time. The cookies, likely, were not installed because there is no vulnerability.
  • 3. Uncertain situation. If the response time differs widely, without coincidence with preset by cookies delay, we can not say for sure. It could be if the server is under high load. To check this, we use two requests with same cookies (#3 and #4). If the response time for two same checks varies, we make a conclusion that the response time is not affected by cookies. At least, not only by them. So in this case our method can not detect vulnerability

Safety of checks

Our test can not damage your server. The risk consists of appearance of one extra-cookie, which is used only for our requests and can not affect normal work-flow of your site.

more blog
Thank you for feedback!
Task events
Sign In
Sign Up
Prices & packages
Our monitoring network
Home > Uptime reports > Task events
Report for:
# of check, count Start Interval Status Location
9009 - 9034, 26 00:12:05 12 hour(s) 30 min(s) Up Tehran, Tehran, Iran, Islamic Republic of
8985 - 9008, 24 12:12:02 11 hour(s) 30 min(s) Up Dallas, TX, United States
8984 11:41:58 Up Kharkiv, Ukraine
confirmed from 7 locations
Up Quincy, WA, United States
Up Cheyenne, WY, United States
Up Dronten, Netherlands
Up Amsterdam, Netherlands
Up Almaty, Kazakhstan
Up Sofia, Bulgaria
Up Manassas, VA, United States
8983 11:11:16 HTTP response timed out Singapore, Singapore
confirmed from 7 locations
ConnectionRefused Amsterdam, Netherlands
ConnectionRefused Cheyenne, WY, United States
ConnectionRefused Quincy, WA, United States
ConnectFailure Almaty, Kazakhstan
ConnectFailure Minsk, Belarus
ConnectFailure Vilnius, Lithuania
ConnectFailure San Jose, CA, United States
8961 - 8982, 22 00:10:55 10 hour(s) 30 min(s) Up Nuremberg, Germany
8913 - 8960, 48 00:25:45 23 hour(s) 15 min(s) Up Hyderabad, Telangana, India
8865 - 8912, 48 00:25:36 23 hour(s) 30 min(s) Up Manassas, VA, United States
8822 - 8864, 43 02:51:23 21 hour(s) 4 min(s) Up Dnipro, Ukraine
8817 - 8821, 5 00:11:03 2 hour(s) 5 sec(s) Up Khmelnytsky, Ukraine
Send to Twitter Send to Facebook Send to LinkedIn Share on Google+
HostTracker blog HostTracker page on Facebook