I want to populate my error log with useful information if and when errors occur. I'd like to use the log to be able to spot and fix bugs on my site, but also to potentially log hack attempts. For a PHP web app, what information is considered vital and why? What info can be useful? What is overkill?

My current list is:

  • The type of error.
  • The corresponding error message.
  • The URL where the error occurred.
  • A timestamp.
  • The user's IP and user agent.
  • The referring URL.
  • 1
    Logging the IP, User-agent, and potentially Referer, could violate privacy acts, but probably only European ones.
    – atdre
    Nov 15, 2010 at 12:05
  • 2
    @atdre, how this could violate privacy acts? IP, User-agent and referer were made with purpose to distinguish software, machines and so on. Those who needs anonymity take appropriate measures. Could you point at where what you have written is clearly stated?
    – anonymous
    Nov 15, 2010 at 16:52
  • 1
    @atdre - Almost every analytics program will record the referrer. Many systems record IP and user-agent to help deal with spammers. I would also love to see where this violates privacy laws. Nov 15, 2010 at 21:14
  • Switzerland, amongst other places. @atdre is correct, there are some strange privacy laws out there. Though I'm not sure if it applies to public websites, or just corporate usage.
    – AviD
    Nov 16, 2010 at 5:54

4 Answers 4


Usually the amount you log depends on the kind of error. The more critical the more you log.

In regards to other stuff you would want to log

  • Filename for the file that caused the error would be high up the list, with line number.
  • Stack trace information if the error was a result of an exception being thrown.

I don't think you can overkill the amount you log when an error occurs as long as its useful. The only time I have seen logs become really bad is when massive logs are being taken even when an error does not occur.

Some more information can be found on the OWASP website - Error Handling and Logging.


I am using Exception shielding pattern.

First of all: application logs all information that I need (as developer) to the database, file...

Second: application returns a message that does not contain sensitive internal information to the client.

Private information (shielded) that application can collect:

  • client environment variables (url, ip, language...)
  • place of error(s): stack
  • my business variables (custom error handling)

I have decided to separate unhandled exceptions and custom handling ones and I have logging templates for every type of exceptions


Mark and igor have good suggestions. I would also advice reading on OWASP about error handling and logging.

One more thing, whatever you log be sure to sanitize logged information that comes from the user, such as url referrer, get/post variables, usernames, etc. In other words anything that can be manipulated by the remote user. You probably don want to end up logging a username that is 100,000 characters long.


In addition to what you mentioned, I would try to include POST values ($_POST) and cookie/session data if available.

  • 1
    Want to add that additional measures should be taken when logging such information - to avoid DoS and other nasty situations. POST can contain large amount of data. For example, without specific control user (attacker here) may be able to take up hard drive space.
    – anonymous
    Nov 15, 2010 at 16:57
  • Another good point, but that of course is assuming it's a website... I would generalize this to say "all input to the system".
    – AviD
    Nov 16, 2010 at 5:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .