Comprehensive web hosting: how to debug errors using log files

Your apache web server log files are accessible via in the following location:


where <your-account> is your SSO username, or your nsms account if you are an external web developer, and <site-name> is the primary virtual host for the contract, if you have more than one site name within a single contract.

The logs are read-only, so are safe from accidental editing. They use a log level of 'info', are rotated every day, and kept for 395 days.
The latest two logs are uncompressed text, older ones are gzipped, so to view these you need to either extract them to a writeable location, or you can use tools such as zgrep / zcat / zless.

The error log is in standard apache format. Since the logs record any messages at 'info' level or higher, you may want to narrow down data by grepping for lines which do not contain [info].

The access log has been customised to include extra useful data. This logging format is:

%{%Y-%m-%d %H:%M:%S%z}t %h %V %u \"%r\" %>s %b

%{%Y-%m-%d %H:%M:%S%z}t is the date in ISO 8601 format, a space, then the time and UTC offset.

%h is the IP address of the client.

%V is the hostname of the server - this is useful if you have more than one virtual host running within a single contract.

%u is the username that the request has come from - for unauthenticated requests this will display as a hyphen.

\"%r\" is the first line of the request, with added surrounding double quotes.

%>s is the http status code of the request, after any internal redirects have been done.

%b is the size of the response in bytes, excluding headers.


A list of HTTP status codes and what they mean is here:

4xx error codes mean a problem with the site content or .htaccess settings, and should be solvable by the site owner.

5xx error codes could mean there is something wrong with the server, although some can also be caused by timeouts due to slow site code, or due to errors in site .htaccess files.

An example of a recent problem that was diagnosed via log files involved a wordpress site that was migrated from a dedicated host, to a site running in a subdirectory.
In order to maintain existing links, the site owner created a .htaccess file which re-wrote requests to include the new subdirectory. At this point the site started giving 500 errors.

Looking in the error log showed:

[Tue Feb 30 12:34:56 1970] [error] [client] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace

Which was enough information to realise that the .htaccess file was causing a re-write loop, and get it fixed.

Get support

Local IT support provide your first line of on-the-spot help



Common requests and fault reports can be logged using self-service




The central Service Desk is available 24x7 on +44 1865 6 12345


If you do not have an SSO account you can use this form to contact the Service Desk