Whats that site running?
Netcraft Services
Sites on the Move
Today's changes
Last week
Last Month
Internet Exploration
Netcraft Toolbar
What's that site running?
Search Web by Domain
Internet Data Mining
Hosting Provider Switching Analysis
Hosting Provider Server Count
Hosting Reseller Survey
SSL Survey
Web Server Survey Archive
Performance
Hosting Providers' Network Performance
Dedicated Server Monitoring
Security
Anti-Phishing Toolbar
Automated Security Testing
Dedicated Server Monitoring
Web Application Testing & Site Audits
Security Services FAQ
Uptime
Longest uptimes
Most requested sites
Advertising
Banner Advertising on Netcraft
About Netcraft
About Netcraft
Jobs at Netcraft
Fair Use, Copyright
Site Privacy Statement
Visiting Netcraft
Contact Us
Webmaster

Frequently asked questions


How do you perform the operating system detection ?


Netcraft determines the operating system of the queried host by looking in detail at the network characteristics of the HTTP reply received from the web site.

The reported operating system may be different to the one you expected because:

  • The site is using a web proxy cache, such as Novell BorderManager FastCache, Inktomi Traffic Server or a server running the open source Squid software. In this situation we will be connecting to the reverse web proxy rather than the originating web server, so will detect the cache's O/S rather than the web server's. Some proxy caching systems add headers to web server responses, such as the standard "Via" header. If the "Via" or "X-Cache" headers are found we report that the site is proxied.
  • The site is using a server load balancing device (SLB) like Cisco Web NS, Resonate Central Dispatch or BIG/ip. Some of these SLBs handle the TCP connection themselves, so we detect the SLB's operating system. Others use TCP/IP packet level Network Address Translation techniques, where we detect the operating system of one of the back-end web servers.
  • The site is using a TCP connection-level proxy firewall, such as provided in the TIS Gauntlet, BorderWare, Raptor, CyberGuard or IBM SecureWay firewalls, or some other kind of HTTP level proxy. In these cases we will receive data from the intermediate machine rather than the web server, so detect the intermediate machine's operating system.
  • The site load shares across multiple servers using different operating systems with round robin DNS. In such cases each query might detect a different operating system.
  • The site has changed the default configuration of their TCP/IP stack, perhaps for performance reasons, or have an unusual LAN environment.
  • We made a mistake. If you see an operating system & web server combination reported that you know to be wrong, please e-mail us.

We can reliably detect the following operating systems:

  • AIX
  • AS/400
  • BSD/OS
  • DG/UX
  • Cisco
  • Compaq Tru64
  • FreeBSD
  • HP-UX
  • IRIX
  • Linux
  • MacOSX
  • NetApp NetCache
  • NetBSD/OpenBSD
  • NetWare
  • NT3/Windows 95
  • NT4/Windows 98
  • OpenVMS
  • OS/2
  • OS/390
  • SCO UNIX
  • Solaris (both Solaris 2 and Solaris 7)
  • Solaris 8
  • Solaris 9/10
  • SunOS 4
  • VM
  • Windows 2000, Windows Server 2003, Windows XP
  • Windows Server 2008/Vista

Why do you sometimes get Windows versions wrong ?


Although we can identify Windows 2000/Windows Server 2003/Windows XP, they all use the same basic TCP/IP stack, and we cannot reliably distinguish between them. The OS detection does the best it can using the server banner, but for people running web servers other than IIS, Windows Server 2003 may be reported when it is actually Windows 2000 or XP in use.

In the same way, Vista and Windows Server 2008 have similar TCP/IP characteristics, so Vista machines are currently reported as Windows Server 2008.

What is 'Uptime' ?


The 'uptime' as presented in these reports is the "time since last reboot" of the front end computer or computers that are hosting a site. We can detect this by looking at the data that we record when we sample a site. We can detect how long the responding computer(s) hosting a web site has been running, and by recording these samples over a long period of time we can plot graphs that show this as a line. Note that this is not the same as the availability of a site.

What is 'Availability' ?


We do NOT currently monitor 'availability'. The 'availability' of a web site is its ability to serve requests. This can be affected by several factors outside the control of site, such as the routing and network performance.

Whilst being related to the uptime it is not a direct relationship, since a site may actually be served by more than one computer at once, balancing the load of requests coming from the users of the network over a 'farm' or group of computers. If one of the computers is rebooted it is not available to serve requests during its reboot phase. When this is happening the other computers in the 'server farm' are handling the requests. So, as far as the users of the site are concerned, the site still has full availability.

This 'server farm' approach is used by many of the largest profile websites to manage the load, but the most typical approach is to use one computer only. In this single computer case clearly the 'availability' is directly affected by the 'uptime'.

Note that we can only detect the 'front end' machines, i.e the ones serving the home page of the site. If a site uses other 'back end' computers for its own private functions we will be unable to detect them.

Which operating systems provide uptime information ?


Operating systems we can usually work out uptimes for are:

  • BSD/OS
  • FreeBSD [but not the default configuration in versions 3 to 4.3]
  • HP-UX [recent versions]
  • IRIX
  • Linux on Intel x86 processor, kernel versions 2.1 to 2.5.24
  • Linux on ARM, M68k, MIPS, PowerPC, S/390, SH and SPARC processors
  • NetApp NetCache
  • Solaris 2.6 and later
  • Windows 2000
  • Windows Server 2003
  • Windows XP

Operating systems that do not provide uptime information include;

  • AIX
  • AS/400
  • Compaq Tru64
  • DG/UX
  • Linux before kernel version 2.1
  • Linux on Alpha and IA64 processors
  • Linux on Intel x86 processor from kernel version 2.5.25 (see below)
  • MacOS
  • MacOSX
  • NT3/Windows 95
  • NT4/Windows 98
  • NetBSD/OpenBSD
  • NetWare
  • OS/2
  • OS/390
  • SCO UNIX
  • SunOS 4
  • VM

Additionally HP-UX, Linux, NetApp NetCache, Solaris and recent releases of FreeBSD cycle back to zero after 497 days, exactly as if the machine had been rebooted at that precise point. Thus it is not possible to see a HP-UX, Linux or Solaris system with an uptime measurement above 497 days.

Why do some Operating Systems never show uptimes above 497 days ?


The method that Netcraft uses to determine the uptime of a server is bounded by an upper limit of 497 days for some Operating Systems (see above). It is therefore not possible to see uptimes for these systems that go beyond this upper limit. Although we could in theory attempt to compute the true uptime for OS's with this upper limit by monitoring for restarts at the expected time, we prefer not to do this as it can be inaccurate and error prone.

Why does my uptime go back to 0 after 198 days ?


The Linux TCP stack uses the low 32 bits from the system uptime timer, and this timer, in recent kernel releases, runs at 250Hz. This means that the timer value wraps around to 0 after roughly 198 days. Although we could in theory attempt to compute the true uptime for OS's with this upper limit by monitoring for restarts at the expected time, we prefer not to do this as it can be error prone.

Why do you not report uptimes for Linux 2.6 or FreeBSD 6 ?


We only report uptimes for systems where the operating system's timer runs at 100Hz or less. Because the TCP code only uses the low 32 bits of the timer, if the timer runs at say 1000Hz, the value wraps around every 49.7 days (whereas at 100Hz it wraps after 497 days). As there are large numbers of systems which have a higher uptime than this, it is not possible to report accurate uptimes for these systems.

The Linux kernel switched to a higher internal timer rate at kernel version 2.5.26. Linux 2.4 used a rate of 100Hz. Linux 2.6 used a timer at 1000Hz (some architectures were using 1000Hz before this), until the default was changed back to 250Hz in May 2006. (An explanation of the HZ setting in Linux.)

FreeBSD versions 4 and 5 used a 100Hz timer, but FreeBSD 6 has moved to a customisable timer with a default setting of 1000Hz.

So unfortunately this means that we cannot give reliable uptime figures for many Linux and FreeBSD servers.

Why do you report impossible operating system/server combinations ?


Webservers that operate behind a caching system, load balancer, reverse proxy server or a firewall may sometimes report the operating system of the intermediate machine. Hence reports of 'Microsoft/IIS on Linux' may indicate that either the web server is behind a Linux server that is acting as a reverse proxy, or has configured the Akamai caching system such that the first request to the site goes to one of Akamai's servers [which run Linux], or as in the case of www.walmart.com has been configured to send a misleading signature.

Why don't you provide data on servers not on port 80?


We only provide data for servers working on port 80 (http). This is to prevent the uptime service being used for port scanning via Netcraft's web server.

How do 'load balancers' affect the information ?


On some regularly monitored sites, reported uptimes may differ significantly from day to day, and the reported operating system and web server may seem to continually change. In these cases the site in question most likely has multiple machines in its pool operating on different Web servers and operating systems. Requests are typically farmed out to the machines by a server load balancing device that hands the TCP requests onto machines in the server pool.

Which sites are routinely surveyed ?


Initially a small set of sites were surveyed, but we are now increasing this set. Any site that is requested through the what's that site running query form at Netcraft.com will be automatically added to the set of sites that are routinely sampled. If you have already done this you do not need to e-mail us. Once we have collected sufficient daily samples, we will be able to plot an uptime graph for the site.

Once we have monitored the host for sufficient time to plot a graph, we will only continue to monitor the host if it is again requested through the site. We cannot routinely monitor all 22 million hosts that we know of for performance reasons.

How often is a site monitored ?


Each site that is in the set of sites to be monitored is queried only once a day. We only do this once, and if the site is unavailable at the time we do it then it will not have a sample recorded that day.

The 'query now' link can be used to perform a query of the site immediately. This will not update the uptime values, just the OS, Server and Netblock information.

How is the 'average' calculated for individual sites ?


For individual sites we take all of the samples within the time window (default 90 days) that provide a reliable uptime figure and sum them, and divide the sum by the number of samples, giving the arithmetic mean. Samples that do not provide an uptime figure, such as those from NT4, are ignored and play no part in the average calculation.

How is the 'average' calculated for 'Netblock Owner's ?


For hosting locations we take all of the calculated averages of the sites within the assigned hosting company netblock, sum them and take an average. Individual sites that do not provide an average figure are not considered when calculating the hosting location average.

How is the 'Netblock Owner' information gathered ?


We collect information from several sources,

  • Europe: RIPE
  • Asia/Pacific: APNIC, AUNIC, CCAIR, JPNIC, KRNIC, TWNIC
  • Americas: ARIN
We then look up the IP address of the site in our database to get the netblocks. We can also map together netblocks. In some cases, where there has been further delegation, we may not be providing the more detailed information that may be available. We are working to improve this functionality.

What can I do if I think the 'Netblock Owner' information is incorrect ?


First you need to ensure that the appropriate NIC entry for your IP address is correct. Follow the links above and navigate to the 'whois' server, and enter your IP address. If your IP address is in a block that has been further delegated we do not currently support a further level of lookup. We are working to improve the depth of coverage of our information in this area.

If the entry is correct and we are not displaying it correctly, please let us know.

How do I read the graphs ?


The graphs for each site display both the actual times since last reboot (as an X) and a moving average of uptime over time as a solid green area graph. The colour of the X changes in the event of the site switching operating system. A history of the operating system, web server and hosting location is also provided so it is possible to correlate these changes with the uptime of the site. When we are unable to get a valid uptime measurement for a site, a gap will appear in the plots of the raw data points.

Queries are made on a daily basis, so the crosses on single server site will appear as a diagonal line moving forward through time until the next reboot. Sites using multiple front end servers with some form of load balancer will show parallel diagonal lines. A good example is the BBC site.

Daily reports are generated showing the sites and hosting locations with the longest uptimes.

Example Site 1 - www.apple.com


Uptime for www.apple.com
Note: Uptime - the time since last reboot is explained in the FAQGenerated on 27-March-2001

Explanation:The chart shows the time since May 1999 when we first started monitoring www.apple.com through to March 2001. Each vertical line on the X axis represents two months. Each small 'x' on the chart represents a reading on a particular day.

In the first few months we can see two blue lines representing the servers servicing the site. They are blue, which represents Solaris in this example. At June 1999 it looks like there are two Solaris servers, one of which is restarted at the beginning of June whilst the other continues to run until the start of July 1999, when it is also restarted.

We can also see at the bottom of the graph the occasional appearance of MacOSX (in pink).

From December 1999 there are more clearly three Solaris servers running with different uptimes. Two of them appear to be restarted at the start of April 2000 to run with very similar uptimes. In June 2000 all three were restarted, and the MacOSX system starts to run in parallel as the Solaris systems are phased out, until it becomes the only operating system servicing the site.

The current versions of this graph can be seen by querying the site.

Uptime Summary for www.apple.com
Note: Uptime - the time since last reboot is explained in the FAQ Time in Days
Plotted ValueNo. samplesMaxLatest
MacOSX156134.5431.06
BSD/OS316.18 16.18
Solaris413180.1825.23
90-day Moving average66997.15813.62
Explanation:This table shows the Maximum and Latest uptimes in days for each of the Operating Systems we have detected. The No. of samples is the number of samples for each type we have recorded, usually one per day.

OS,Web Server and Hosting History
OS Server Last changed IP address Netblock Owner
MacOSX Apache/1.3.9 (Mac OS X Server) 10-Jan-2001 17.254.0.91 Apple Computer, Inc.
Solaris Netscape-Enterprise/3.6 SP3 9-Jan-2001 17.254.0.91 Apple Computer, Inc.
MacOSX Apache/1.3.9 (Mac OS X Server) 16-Dec-2000 17.254.0.91 Apple Computer, Inc.
Solaris Netscape-Enterprise/3.6 SP3 15-Dec-2000 17.254.0.91 Apple Computer, Inc.
MacOSX Netscape-Enterprise/3.6 SP3 15-Dec-2000 17.254.0.91 Apple Computer, Inc.
MacOSX Apache/1.3.9 (Mac OS X Server) 7-Dec-2000 17.254.0.91 Apple Computer, Inc.
MacOSX Netscape-Enterprise/3.6 SP3 6-Dec-2000 17.254.0.91 Apple Computer, Inc.
MacOSX Apache/1.3.9 (Mac OS X Server) 27-Nov-2000 17.254.0.91 Apple Computer, Inc.
Solaris Apache/1.3.9 (Mac OS X Server) 26-Nov-2000 17.254.0.91 Apple Computer, Inc.
MacOSX Apache/1.3.9 (Mac OS X Server) 24-Nov-2000 17.254.0.91 Apple Computer, Inc.

Explanation: From this table we can see that IP address has remained constant, even though we are detecting several different Operating Systems at this address. This and the graph above confirm that there is more than one type of Operating System in use in parallel.

Example Site 2 - www.telewest.co.uk


Uptime for www.telewest.co.uk
Note: Uptime - the time since last reboot is explained in the FAQGenerated on 28th March 2001

Explanation: Telewest is an example of site that has gone through a number of Operating Systems and Web Servers in recent history. The chart above shows them starting out with IRIX, then changing overnight to Linux, followed by the current HP-UX.

Note the scale of the chart, each Operating System ran for more than 50 days before being restarted. Note also the initial value for Linux, at mid March 2000. This had been running for 60 days when the IRIX system was switched over to the Linux one, although it was restarted a few days later before running up to 60 days again. Simillarly the HP-UX system has been running for approximately 40 days before it started to serve the live site.

The current versions of this graph can be seen by querying the site.

If you still don't see a reasonable explanation for the data you are looking at, please tell us.

How can I use this information from my own site ?


You can link to the Netcraft What's that site running ? form from your own site, and use our 'Powered By..' Logo too, just cut and paste the code.

How can I be informed of survey news and developments ?


We can update you with the most recent survey results and news of other developments at Netcraft. Details are here.

Your comments and suggestions are most welcome webmaster@netcraft.com © Netcraft 2007