Wordpress, Elementor and the mysterious server error (500 error)

Written by - 0 comments

Published on - Listed in PHP Wordpress Internet HTML Linux


For my wife's business I manage a website that uses WordPress in the background. The pages are made with Elementor, which is a powerful WYSIWYG online-editor to create pretty nice designs.  

Over the years the site constantly grew, gotten some replacements, etc. A typical case of a "living" website, held up to date. Every update has worked fine so far, until yesterday.

The mysterious server error

I continued making changes on the front page and published them. However when I wanted to look at the changes in a different browser, the changes did not show.

It took me a while to realize it, but when I hit the "Publish" button (at the top right) in Elementor, at the bottom left an error was showing up for a couple of seconds:

Elementor showing server error (error 500)

Being primarily a server admin guy, I checked the server logs (web server access and error logs). And indeed, a POST request returned an internal server error:

xxx.xxx.xxx.xxx - - [05/Mar/2026:20:36:34 +0100] "POST /wp-admin/admin-ajax.php HTTP/1.0" 500 754 "https://www.example.com/wp-admin/post.php?post=5879&action=elementor" "Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0" 

That was indeed my request inside Elementor, trying to publish the changes.

The bigger problem though - and this is why I call this mysterious - was the fact, that nowhere else an error was logged. Typically when you get an internal server error, the web server's or PHP error log would reveal some fatal error in the code execution. 

But neither the web server's error log, nor PHP log, and not even WordPress with DEBUG_LOG enabled logged anything useful, which would explain the internal server error. 

Research leads to the revisions (and the memory usage)

After a (meanwhile becoming legacy/classic) research on the Internet, one specific WordPress support thread caught my eye. One of the developers responded to the OP:

> When there are too many revisions stored, the hosting memory may become exhausted, which can lead to this error.

Could this be an exhaustion of PHP's memory_limit? The domain and its own PHP-FPM pool are configured with a memory_limit of 256M. Is this not enough anymore?

Note: Usually exhaustion of PHP's memory_limit result in an error, clearly highlighting issues with the memory_limit being reached (tried to allocate...). But in this situation nothing was logged at all. Hence: Mysterious!

After checking out the revisions in Elementor, which I've never looked at before, I started to understand.

Elementor revisions

A ton of revisions were listed, dating back to the beginning of December 2025. If each revision is being held in memory for the possibility to revert a change... well then yes, I can actually believe that this could fully use the memory limit of the PHP process.

Memory increase in PHP pool

Although no PHP errors were logged that would point to memory exhaustion or reaching the memory_limit, it's so far the most plausible cause. 

Let's try and increase from 256M to 512M.

root@webserver:~# grep memory_limit /etc/php/8.4/fpm/pool.d/www-data.conf
php_admin_value[memory_limit] = 512M 

root@webserver:~# systemctl restart php8.4-fpm

Right after this, I tried again to do some changes in Elementor and clicked on publish. This time with success; the changes were successfully saved and published on the front page! 

This means it was indeed a problem with the size of the front page, the number of changes/revisions of the page and the current PHP memory_limit.

Setting a limit on the revisions

I asked the WordPress experts from the Digital Web Agency WEBKINDER, whether they ever experienced a problem like this before. They've shared a nice code snippet with me, that limits the number of page revisions in WordPress:

add_filter('wp_revisions_to_keep', function (int $num, WP_Post $post) {
    return post_type_supports($post->post_type, 'revisions') ? 30 : 0;
}, 10, 2);

This snippet can be placed into the theme's (or better: child theme) functions.php. 

WordPress + Elementor + many elements = Lots of memory usage

Luckily the WordPress website in question runs on a dedicated and WordPress optimized LAMP server. With a dedicated server the PHP's memory_limit could easily be increased to fit the needs. Using this kind of "heavy" WordPress setup requires much more memory than a standard site, hence it would (probably) never work on a shared hosting server - or it would but very slowly.

The golden rule is therefore: If you run a business website and you run Elementor on top of WordPress with many elements on your page, go for a dedicated server


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Observability   Office   OpenSearch   PHP   Perl   Personal   PostgreSQL   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder