Automatically email the content of a PHP error log file

I have just been playing around with a script that might be of interest to some people. It is a cron to automatically email the content of a PHP error log file.

I found it here:

It works really well. You define the error file location you want to monitor (for me it was /home/xxxxxxx/public_html/error_log) and set up an email method (I used the SMTP option). Then set it to run as a cron job. It checks if the file is empty and, if not, it emails you the contents (there is a setting to limit the size but I removed that). Then it moves the contents of the file to an archive file, so you go back to having an empty error file.

I like to keep an eye on all these error messages but it’s a chore with about 20-25 sites, so this is a nice way to monitor for any potential problems.


I also find it tedious to get at my (live http) error logs and have been thinking about ways to solve it. My thoughts were to display the contents of the file to the specified roles (or capabilities) in a dashboard view…with a single menu item for “Error Log”, probably under the “Tools” menu. Emaling the logs is handy when you’re not on the site; I like this. If you’re doing something on the site, having a dashboard page that you can refresh repeatedly would be handy also (to avoid clogging your inbox in the case of repeated errors.)

1 Like

This plugin shows the error log in the admin Dashboard.

1 Like

I like the way it sends them, then clears them out. I will often check the error file when I am in with ftp, and generally delete the contents, but I forget which I have done and what I have seen.

This way I am notified and they are removed. I’ll have to wait and see if the clogged inbox issue becomes annoying though.

1 Like

Thanks Joy. I always tend to look for “non-plugin solutions” if possible so I hadn’t seen that.


Can you explain that thought process? Is it the fact that someone else wrote the code? Or that it’s not in the WP repository? Or that you want to figure it out?
I’ve seen so many support requests saying “I want to do X and Y, but without a plugin.” Is this the same thing?

I can’t speak to Alan’s reasoning, but, I know some users take this approach because there’s a myth that less plugins = faster site. So, they add it all to the functions.php file (or maybe a utility plugin) in an effort to get better performance.

It’s an instinctive thing, but when I think about it there are a number of reasons:

  1. I like to figure things out myself.

  2. I think minimising plugins will minimise the maintenance requirements and potential problems. I provide fully managed hosting so whenever I update anything on a site (theme or plugins) I always have to go over the site to make sure nothing is broken. It’s become slightly more of a concern now since I’m mostly using CP and plugins need to be WP4.9 compatible.

  3. I want any important maintenance processes to be outside of WP/CP. So, for example, I would never use a backup plugin. The same as I never rely on cPanel backups provided by my hosting company.

  4. Plugins invariably provide ten times more functionality than I need, and I like to reduce bloat. This is even more of an issue now as themes and plugins start including Gutenbloat.


I like the idea of this but wouldn’t you be concerned about potential security risks of emailing your error logs? It depends on your PHP reporting level but quite often the PHP error logs can reveal information you might not want others to see.

I think I’d only do this if using PGP encryption or if the error log is compressed and encrypted first. But there again, I am slightly paranoid when it comes to security. :slightly_smiling_face:

1 Like

The main issue to me is that 3d party plugins tend to overgrow and to add excessive features and optional functionality.

Typically you install something like “The Simlpest Lightbox Forever” with 10 strings of code inside, but 3-5 years after it appears to be “The Mega Universal Media Gallery with Super-duper Cloud Features and Native Youtube Support Right From the Box”. And if site goals doesn’t match author’s vision or trends, plugin remains almost unused. But you still have to carry 95% of unused code from project to project and apply tons of disablers, tweaks, filters. And each stuff generates notices, sends emails, asks for donations, injects bugs and then releases fixes.

For example I have ~20-50 strings in my functions.php just to disable some Yoast SEO features. E.g. “readability analyses” which is incorrect for my language (for now), “primary term taxonomies” that I don’t use, notifications etc.

It’s rather hard to manage tons of plugins when supporting 20-50 sites. Sometimes you have to keep monster plugins just for legacy reasons. Such projects tend to become oversized and slow if you don’t fix things manually from time to time. And if you switch some projects to newer and simplier plugins, your common stack of support grows (and probably you’ll face the same trouble with younger ones in 2-3 years again). And you can’t just disable updates, as you still need to get bugfixes and patches and keep them up to current CMS version.

So I usually have to choose environmental plugins (e.g. ACF, Woo) that I suppose would match main site goals for a long distance (1-3 years at least). But avoid third-party solutions for implementing small features becuse it’s often cheaper to support 10 direct strings in functions.php (or self-made plugin).

1 Like

This never occurred to me and I really have no idea about the security risks. There doesn’t seem to be anything in there that might give hackers a way in, but I could easily be wrong about that. :slightly_smiling_face:

1 Like

Admittedly the risk is small but it’s essentially the same reason why you hide errors from the frontend. The errors can give away information such as the name of functions, paths, malformed SQL queries etc. which I’m sure you’re already familiar with. Generally not info you’d want others to see. My problem with emailing them is that email is not secure and can be intercepted even if using SSL/TLS. I would prefer to password encrypt the file before emailing it. Or set up a scheduled SSH connection to download the file(s). But as I say, I am slightly paranoid about these things.

1 Like