WooCommerce Disk Space Full? Fixing a Bloated Error Log

When Your WooCommerce Disk Space Is Suddenly “Full”

If you run a WooCommerce store long enough, you’ll eventually get that dreaded notice in your hosting panel: “WooCommerce disk space full”. On one client site, the warning arrived out of the blue. Nothing major had changed – no big new product imports, no media dump – yet the hosting account was chewing through gigabytes as if someone had turned on a tap.

A quick look at the account confirmed the problem: the site itself wasn’t that large, but the error_log file was ballooning. In our case, it was growing by around 20 MB per hour. At that rate, WooCommerce disk space full is not a figure of speech, it’s a matter of days. Backups get bigger, restores get slower, and sooner or later the site will hit its hosting limits at the worst possible time.

This article is a short case study of what we found, how we fixed it, and what you can do if your own WooCommerce store starts eating disk space far faster than it should.

Chasing the Bloat: Why Is My WooCommerce Disk Space Full?

The first stop was the hosting file manager. Themes, plugins and uploads all looked normal for a busy WooCommerce shop. The real offender was sitting quietly in the site root: error_log, already hundreds of megabytes in size and growing every few minutes.

Opening the file made the pattern obvious. The same database error was being logged over and over:

WordPress database error Table 'prefix_actionscheduler_actions'
is marked as crashed and should be repaired for query
SELECT a.action_id FROM prefix_actionscheduler_actions a
WHERE a.hook = 'woocommerce_pdf_invoice_delete_files' ...

Different hooks, same message: a single table – the Action Scheduler actions table – was marked as crashed. WooCommerce, extensions, and even some core WordPress routines rely on Action Scheduler for background jobs, so every page load and every cron run was trying (and failing) to touch that table. Each failed attempt meant another line in error_log. For many store owners, this is exactly when the hosting panel starts shouting “WooCommerce disk space full”.

In other words, the store didn’t suddenly become huge overnight. A low-level MySQL glitch clipped one high-traffic table, and the resulting stream of database errors quietly filled the disk. Next step: repair the table and then clean up the mountain of old scheduled actions left behind.

Before You Touch the Database: Read This First

With that out of the way, let’s look at how we safely repaired the crashed Action Scheduler table and stopped the “WooCommerce disk space full” situation from getting any worse.

Step 1: Repair the Crashed Action Scheduler Table

Once we knew the error_log was being flooded by database errors, the next job was to fix the actual problem: the Action Scheduler table MySQL had marked as crashed. Until that table was healthy again, WooCommerce and its extensions were going to keep hammering the log and pushing WooCommerce disk space toward full.

Finding the Broken Table in phpMyAdmin

On this store, the tables were prefixed, so the real names looked like wpgm_actionscheduler_actions and wpgm_actionscheduler_logs. Your site will use a different prefix, but the pattern is the same:

• prefix_actionscheduler_actions
• prefix_actionscheduler_logs

In phpMyAdmin we:

1. Selected the correct database for the WooCommerce site.
2. Scrolled down the table list until we found the actionscheduler_* tables.
3. Noticed that one or more tables were marked as “in use” or “crashed”.
4. Ticked the affected tables.
5. Chose “Repair table” from the “With selected” dropdown and clicked Go.

What Happens After the Repair

If the repair succeeds, MySQL quietly fixes the underlying table structure and index data. From the WooCommerce side, that means:

• New background jobs can be inserted again.
• Existing scheduled actions can be read and processed.
• The stream of “table is marked as crashed and should be repaired” messages in error_log stops.

At this point, the database is no longer actively breaking things, but we’re left with a second problem: a huge backlog of failed, stale and completed scheduled actions sitting in that table. In the next step, we’ll trim that backlog down with some careful SQL so the store isn’t dragging around tens of thousands of dead background jobs.

Step 2: Cleaning Up a Bloated Queue of Scheduled Actions

Repairing the table stops new damage, but it doesn’t magically tidy up the mess that’s already there. In our case, the Action Scheduler tables were carrying:

• Thousands of failed jobs created while the table was broken.
• A mountain of old pending actions that were never going to run.
• Over 140,000 completed actions going back months.

Action Scheduler is essentially a job queue plus history log. Old records are useful up to a point, but if you let them pile up forever they become pure database bloat – more disk use, slower queries, and bigger backups. On a small to medium WooCommerce site, trimming this history is one of the easiest ways to stop “WooCommerce disk space full” from becoming a recurring theme.

Important: Work on the Right Tables Only

All of the SQL below assumes a table name in this format:

prefix_actionscheduler_actions

Replace prefix_ with your actual table prefix (for example, wpgm_), and double-check you are editing the correct database. Do not run these queries on your orders, posts, or any other tables.

2.1 Remove All Failed Actions

Failed actions created during the crash weren’t going to succeed if retried; they were just noise. We cleared them all with:

DELETE FROM `prefix_actionscheduler_actions`
WHERE `status` = 'failed';

This only touches the Action Scheduler queue. It does not delete WooCommerce orders or products.

2.2 Clear Stale Pending Actions

Next, we removed pending actions that were clearly never going to run – for example, anything older than 30 days:

DELETE FROM `prefix_actionscheduler_actions`
WHERE `status` = 'pending'
  AND `scheduled_date_gmt` < (NOW() - INTERVAL 30 DAY);

You can adjust the interval if you need a longer history, but 30 days is a reasonable window for most stores. This one query can remove tens of thousands of pointless “pending” jobs in a busy shop.

2.3 Trim Old Completed Jobs

Finally, we trimmed the historical “complete” rows so that only recent activity was kept. Again, 30 days was a sensible compromise between visibility and bloat:

DELETE FROM `prefix_actionscheduler_actions`
WHERE `status` = 'complete'
  AND `scheduled_date_gmt` < (NOW() - INTERVAL 30 DAY);

In the real store this case study is based on, that single query removed around 141,000 rows. Afterwards, the Action Scheduler screen showed:

• A small, current set of completed tasks.
• A manageable number of pending jobs.
• No huge backlog of failed or ancient actions.

The net effect was a leaner database, smaller backups, and one less source of unnecessary disk usage alongside the error log itself.

Action Scheduler is essentially a job queue plus history log. Old records are useful up to a point, but if you let them pile up forever they become pure database bloat – more disk use, slower queries, and bigger backups. On a small to medium WooCommerce site, trimming this history is one of the easiest ways to stop “WooCommerce disk space full” from becoming a recurring theme.

What This Means for Your Store (and Your Disk Space)

The main lesson from this case is simple: when your host warns that “WooCommerce disk space full”, it isn’t always because of images or product data. Sometimes it’s a single broken table and a noisy error log quietly eating gigabytes in the background.

In our case, the fix was in three parts:

• Identify that error_log was the real source of the bloat, not uploads or plugins.
• Repair the crashed Action Scheduler table so WooCommerce could run its background jobs again.
• Prune tens of thousands of failed, stale and old completed actions so the database wasn’t carrying dead weight.

Of course, the error log is only one way a WooCommerce site can get fat. Product feeds, large image libraries and old imports can chew through storage too – we cover those issues separately here: managing WooCommerce product feeds. And if you’d like to see how quickly this can get out of hand, there’s a good example of a store growing by roughly 1 GB per day in this discussion: store disk usage growing by 1GB per day. Both are well worth a read if you’re trying to keep your store lean.

If you’re already staring at a “disk almost full” warning and an error_log that never stops growing, this is exactly the kind of thing we fix for clients. We locate the real source of the bloat, repair what’s broken, and clean up safely so your WooCommerce store has room to breathe again.

External References

Internal Sydney Business Web Links