How to flush expired transients in WordPress

Transients are WordPress's built-in temporary cache, stored in wp_options with an expiry time. When the expiry passes, WordPress only deletes the row the next time that exact transient is requested, which for many never happens. Expired transients pile up, and because many are autoloaded, they are read into memory on every page load. The fix is to delete expired transients and keep them from rebuilding into bloat.

What causes this?

Plugins cache API responses, feeds, and computed data as transients. When a plugin is removed or a feature stops being used, its transients stay behind, expired but never requested, never cleaned. On sites without object caching they all live in wp\_options, the most sensitive table in WordPress.

How to check

Count the transients that expired but are still in the table:

SELECT COUNT(\*) FROM wp\_options
WHERE option\_name LIKE '\_transient\_timeout\_%'
AND option\_value < UNIX\_TIMESTAMP();

That is the count of expired-and-still-present transients. Hundreds is common; thousands is a problem.

How to fix it manually

1. Back up the database

1. Delete expired transients with WP-CLI

wp transient delete --expired. To clear all transients (they rebuild as needed): wp transient delete --all.

1. If the count regrows fast, identify the producer

By prefix in option_name, then review that plugin.

1. Consider a persistent object cache

See the object cache fix, which moves transients out of the database entirely.

How BoltAudit does it

The audit runs all of the above for you and turns it into one reviewed action.

1Finds it automatically with the count and combined size as evidence.

2Preview the exact change. How many expired rows will be removed.

3Automatic backup, then flush in one click.

4Roll back any time; transients also rebuild themselves harmlessly on demand.

Fix this on your site

Common questions

Is it safe to delete transients?

Yes. They are caches by design. Anything needed is regenerated on the next request.

Why does WordPress not clean them itself?

It cleans lazily, only when a transient is requested after expiry. Orphaned ones are never requested.

Will pages be slower right after flushing?

The first request that rebuilds a given cache does a little extra work. It is not noticeable in practice.

How often should this run?

The audit re-checks on every run; a scheduled audit keeps it from ever piling up again.