“Filling in progress” that does not move for days is almost never a catalog-size problem. It is a background job, Action Scheduler or WP-Cron, that stopped running. WooCommerce ships CLI commands to abort and restart that job directly. None of this touches InstantFilter: it builds its own index during a sync you trigger yourself, with no scheduled action to stall.
What does “Filling in progress” in WooCommerce → Status → Tools mean?
Under WooCommerce → Status → Tools sits “Regenerate the product attributes lookup table”. Run it, and the row changes to “Filling in progress (N)”, where N is a count of products processed. That number should climb every few minutes as a scheduled action, the same Action Scheduler WooCommerce uses for other background work, processes one batch and queues the next. By default a batch is 10 products, a figure WooCommerce documents directly on the wc palt CLI reference.
If you are searching woocommerce product attributes lookup table stuck or filling in progress not moving, the number you are staring at has stopped climbing. That is not the table telling you it needs more time. It is a queued action that never ran, or ran once and failed.
Why does regeneration stall instead of finishing on a large catalog?
A real case on the WooCommerce.com forum shows the pattern on a 30,000-product store: the tool sat at “Filling in progress (300)” for several days, with a large number of woocommerce_run_product_attribute_lookup_update_callback actions queued and some of them failing. The store owner ran wp wc palt regenerate --batch-size=50 by hand and hit a dependency-injection error in the logs, Alias (...LookupTableDataRegenerator) is not being managed by the container — a sign the WooCommerce install itself had a partial or corrupted state, not that 30,000 products is inherently too many for the table.
A second, more common root cause shows up in a separate support thread: WP-Cron disabled in wp-config.php via define('DISABLE_WP_CRON', true), with no server-side cron job configured to replace it. Scheduled actions, including the lookup-table regeneration, then only run when a visitor loads a page and triggers the pseudo-cron, which on a quiet staging site or a cached storefront can mean they barely run at all. The same thread names a specific culprit: a hosting optimizer plugin (SiteGround Optimizer, in that case) silently blocking cron jobs. Neither cause is about the number of products. Both are about whether the scheduler that drives the batches is actually executing.
How do you confirm Action Scheduler is the blocker before you touch anything?
Before running a command, read the evidence. WooCommerce → Status → Scheduled Actions lists every queued job by hook name; filter for woocommerce_run_product_attribute_lookup_update_callback or woocommerce_run_product_attribute_lookup_regeneration_callback and look at two things: whether the “Pending” count is actually shrinking over a few minutes, and whether any entries sit in “Failed”. A pending count frozen at the same number for an hour, with no failed entries either, points at the scheduler itself not firing — usually WP-Cron. A growing list of failed entries points at an error inside the regeneration code itself, which the forum case above shows can happen on an install with a partial or inconsistent WooCommerce state.
To check WP-Cron specifically: search wp-config.php for define('DISABLE_WP_CRON', true), and ask your host whether a server-side cron job hits wp-cron.php on a schedule. WooCommerce’s own support staff, answering the stuck-regeneration thread, recommended the WP Crontrol plugin for exactly this: it lists scheduled events, shows which ones are overdue, and lets you fire one manually to see whether it completes or errors. If WP-Cron is disabled and no server cron replaces it, every background job on the site runs late or not at all — the lookup table is one symptom of a wider problem, not an isolated bug in that one tool.
How do you unstick a stalled regeneration with WP-CLI?
WooCommerce’s own CLI reference for wc palt gives the exact sequence, and it matters which command you reach for. wp wc palt initiate_regeneration starts the same scheduled-action path as the button in Status → Tools — if that path is what stalled, running it again stalls the same way. wp wc palt regenerate instead processes every batch synchronously inside the command itself, with no scheduled action in between, so it either finishes or reports a visible error in your terminal.
First, abort the stuck run and clear its progress data:
wp wc palt abort_regeneration --cleanup
Then run the regeneration synchronously, with a batch size larger than the default of 10:
wp wc palt regenerate --force --from-scratch --batch-size=100
If scheduled actions are the actual blocker and you want to keep using the background path rather than a synchronous run, wp action-scheduler run forces the next pending batch to process without waiting for cron. On a store with tens of thousands of products and a history of failed actions, community troubleshooting in the forum case above also points at raising PHP’s memory limit and max_execution_time for the duration of the regenerate command — that is a server-resource adjustment for a one-off batch job, not a setting InstantFilter or WooCommerce require permanently.
Does a stuck regeneration mean filtering is broken right now?
Not necessarily. The lookup table fills incrementally, so a store with “Filling in progress (300)” out of 30,000 products has a partially populated table. Attribute filters that depend on the rows already written can keep returning results; filters touching products not yet processed can show wrong or missing counts until their batch runs. That is a data-freshness problem, separate from the request-per-click architecture covered in the performance guide. A stuck regeneration does not make admin-ajax.php fire less often, and it does not free a single PHP worker — the filter click still boots WordPress whether the table behind it is 1% or 100% filled.
Why doesn’t InstantFilter have this failure mode?
InstantFilter never reads or writes wc_product_attributes_lookup, so it has no dependency on whether that table’s regeneration finished. Its own indexing step, documented in the docs, runs when you trigger a sync from the admin, builds the index directly, and exports the compressed codebook the browser downloads. There is no Action Scheduler queue to stall and no WP-Cron dependency in that loop: the command either completes or it reports an error, there is no “Filling in progress” state that can sit unchanged for days. The two systems solve adjacent problems — WooCommerce’s table speeds up a server-side query that still runs on every click; InstantFilter removes that click from the server entirely once the index is built.
That also means the WP-Cron and hosting-plugin issues described above are specific to WooCommerce’s own table. If your host silently disables cron for performance reasons, that can still stall other WooCommerce background jobs — order emails, subscription renewals, the lookup table — independent of which filter plugin runs on your category pages. Fixing cron is worth doing on its own merits, not only to unstick a filter count.
For an agency inheriting a store with a frozen “Filling in progress” row, the practical order is: read Scheduled Actions first, fix the scheduler if it is the cause, run wc palt from the CLI once cron is confirmed healthy, and only then decide whether the filter plugin itself needs to change. Swapping the filter plugin does not clear a stuck regeneration, because the regeneration belongs to WooCommerce core, not to whichever plugin reads the table afterward.
Keep going
A stuck regeneration is one failure mode of the lookup table. These pages cover the rest of the request.
- When the table finishes but the click is still slow
- When the count is zero for a different, WPML reason
- Another "stuck" symptom: Cloudflare blocking the request
- The previous generation: wp_postmeta
- Why every click calls admin-ajax.php
- Filters filling PHP workers
- Why WooCommerce filters get slow
- Pricing and trial
