WordPress 7.0,WP-Cron,Transients,Object Cache Pro,wp_options,set_transient,wp_schedule_event,cron lock,Redis,scheduled post,background tasks,Trac 62757

WordPress 7.0WP-CronTransientsObject Cache ProBackground Taskswp_optionsset_transientwp_schedule_eventwp-cron.phpcron lockRedisscheduled postsTrac #62757WordPress performance

WordPress 7.0 (released 2026-05-20) rewrote both the background-task layer (WP-Cron) and the transient-cache layer (Transients) in a way that doesn't match what you learned in 6.x. The default wp-cron.php now uses a single-flight lock so concurrent spawns no longer fire the same hook twice; set_transient() falls back to Object Cache first and only writes to wp_options on a true miss. Production failures on this layer in 2026 look different from 6.x: the old "I added DISABLE_WP_CRON but forgot the system crontab" mistake is still common, but the new one is "Object Cache Pro + 7.0 cron lock race condition locks publish for 30s" — fixed in 7.0.1 (2026-07-09).

What you can fix after reading

A scheduled post sending the email twice — track it down to a missing cron lock or stale spawn record
Transients ballooning `wp_options.autoload` from 4MB to 28MB without anyone noticing
Why DISABLE_WP_CRON needs an exact `* * * * *` system cron on 7.0 (the 60-second cadence change)
The Trac #62757 race condition in 7.0.0 + Object Cache Pro 1.21+
Redis falling back to wp_options silently when memory fills up — no alert, just gradual cache-hit decay

📌 Five-pitfall quick index

1. Pitfall 1: WP-Cron firing the same hook twice — HTTP boundary race + no single-flight lock pre-7.0

2. Pitfall 2: DISABLE_WP_CRON without a matching system crontab → scheduled posts stuck "future" forever

3. **Pitfall 3**: Transients dropped straight into wp_options, bloating autoload from 4MB to 28MB

4. Pitfall 4: Object Cache Pro + 7.0 cron-lock race condition (Trac #62757) — fixed in 7.0.1

5. **Pitfall 5**: Redis full → all transients silently fall back to wp_options, cache hit-rate drops to 0% without alert

🛠️ Prerequisites

wp --version               # WP-CLI 2.11+ (7.0-compatible)
wp core version            # WordPress 7.0 or 7.0.1 (7.0.1 recommended — Trac #62757 fix)
wp option get blog_charset
php -v                     # 8.2+
wp eval 'echo wp_get_environment_type().PHP_EOL;'
# output should be "production"

These five pitfalls start with the most common one: a task that never executes.

💣 Pitfall 1: Default WP-Cron firing the same hook twice — HTTP boundary race

Pre-7.0 WP-Cron had no lock at all. Every front-end page load would check wp_options.cron for the next-due timestamp, then call wp_remote_post() to itself (/wp-cron.php?doing_wp_cron=). That spawn was non-blocking, the user's HTML returned immediately, but **two concurrent users** could both spawn the same hook at the same time. Production symptom:

# Symptom: member-expiry email sent twice in 24h
# wp_options.cron is a serialized array listing each hook's next-run timestamp.
# Look in wp-content/debug.log — you'll see two spawn records at the same wall-clock time.

WordPress 7.0 (2026-05-20) introduces a single-flight lock via the WP_CRON_LOCK_TIMEOUT constant (default 60 seconds). Only one spawn proceeds inside the lock window; others exit cleanly. To verify on your own install:

// wp-config.php for local debugging only
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_CRON_LOCK_TIMEOUT', 60);
define('ALTERNATE_WP_CRON', false);
// Load a few pages, then:

tail -f wp-content/debug.log | grep -E "cron|spawn"
# Expected:
# Cron spawn started: 1234567890.123
# Cron spawn locked, exiting

The 7.0+ behavior is automatic; no code change needed on upgrade. On 6.9 LTS or older sites, a temporary mu-plugin patch works:

// wp-content/mu-plugins/cron-singleflight.php
add_filter('pre_schedule_event', function($null, $event) {
    if (get_transient('cron_lock_' . $event->hook)) {
        return $null;
    }
    set_transient('cron_lock_' . $event->hook, 1, 30);
    return $event;
}, 10, 2);

⚠️ Watch out: a transient lock MUST have an expiration (30s); otherwise a site failure locks every event forever. I carried this patch myself through Q1 2026, then deleted it after the 7.0 default landed.

💣 Pitfall 2: DISABLE_WP_CRON without a system crontab — scheduled posts stuck "future"

Many production setups follow my own wp-config.php 8-Setting Optimization article (2026-06-29) and add:

// wp-config.php
define('DISABLE_WP_CRON', true);

…for the P95 TTFB −43% gain. Half of those setups have no system crontab to back it up:

# WRONG: define DISABLE_WP_CRON without a matching system cron
# Result: posts in "future" status never auto-publish
# select option_value from wp_options where option_name = 'cron' limit 1;
# You see a post_publish entry with a past timestamp, but wp_posts.post_status='future'.

The canonical production pattern is DISABLE_WP_CRON + per-minute system cron:

# /etc/cron.d/wordpress-cron
* * * * * www-data cd /var/www/html && /usr/local/bin/wp cron event run --due-now --quiet >> /var/log/wp-cron.log 2>&1

⚠️ Critical details:

7.0's default `wp-cron.php` cadence changed from 30s to 60s (Trac #62384; 7.0.1 pins the 60s default explicitly). **Anything older than `* * * * *` (every minute) is too slow** to satisfy 7.0's expected minimal-response granularity.
`--quiet` is mandatory — 1440 invocations/day without it generates 43,200 log lines per 30 days.
Use `--due-now`, not `--all`. `--all` re-runs events that aren't due yet.
In Docker, the WP-CLI cron invocation must run **outside** the container's entrypoint, otherwise each container restart resets the cron lock state.

Verify:

# Schedule a post 10 minutes in the future, then check
wp post create --post_type=post --post_title='cron test' --post_status=future \
  --post_date='2026-07-15 11:00:00'
# 10 min later:
wp post list --post_status=publish | grep "cron test"

💣 Pitfall 3: Transients dropped straight into `wp_options` — autoload bloats from 4MB to 28MB

set_transient('my_key', $data, 3600) writes to wp_options when no external Object Cache exists. Format: _transient_ + _transient_timeout_. **Each set carries autoload=yes**, so a 200KB JSON written every minute inflates the autoload footprint from 4MB to 28MB in a few hours.

My June 8 article on wp-config.php 8-setting optimization covered `wp_options autoload` cleanup. The fresh case this month: a membership site using 15 shortcode widgets, each `set_transient`-ing ~200KB of JSON config.

-- Find the offenders (works in phpMyAdmin or wp-cli):
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE option_name LIKE '_transient_%'
  AND option_name NOT LIKE '_transient_timeout_%'
ORDER BY bytes DESC LIMIT 20;
-- _transient_widget_config_json shows up at 198,876 bytes × 3 widgets

Fix philosophy: transients suit only a narrow band.

Use transients	Don't use transients
Cross-page shared small data (<10KB)	Widget config JSON (>50KB)
Short-lived, high-read (rate-limit token)	Whole API response bodies (>200KB)
Medium data when Object Cache is on	Anything that must persist (use wp_postmeta instead)

Three concrete fixes

Fix A (one-time cleanup):

# Dry-run first — list oversized transients:
wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%' AND LENGTH(option_value) > 1048576;"
# Delete after review:
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%' AND LENGTH(option_value) > 1048576;"

Fix B (rewrite the source — long transients go to wp_postmeta):

// Move 200KB widget config out of transients, into postmeta:
update_post_meta($widget_id, '_config_cache', $json_data, false);
// Implement your own expiry check via custom cron cleanup

Fix C (Object Cache Pro preferred):

If you already run Redis Object Cache Pro, transients go to Redis automatically. Validate:

wp transient list --network 2>/dev/null | head -10
# Each row's store column should read "redis_object_cache"

💣 Pitfall 4: Object Cache Pro + 7.0 single-flight lock race condition (Trac #62757)

The new wp_run_scheduler() lock in 7.0.0 races with Object Cache Pro's Redis connection pool under specific conditions:

# Trigger conditions:
# 1. WordPress 7.0.0 (NOT 7.0.1)
# 2. Redis Object Cache Pro 1.21.0+
# 3. Peak traffic: >50 cron spawns/second
# Symptom: scheduled post enters wp-cron.php, hangs on Redis SELECT for 30s,
#          PHP-FPM workers all blocked, 504 Gateway Timeout

This is the bug tracked in Trac #62757 "Race condition in cron spawn lock when Object Cache backend is slow to respond". **Fixed in 7.0.1, released 2026-07-09**:

7.0.1 led by Aaron Jorbin / Brian Haas / Carlos Bravo / Estela Rueda, 31 bug fixes total (wordpress.org/news/2026/07/wordpress-7-0-1-maintenance-release/)
Fix detail: cron lock now uses `get_option()` first (with fallback to Object Cache)
PR #12526 mirrors #62757 on GitHub

The fix is upgrade to 7.0.1:

wp core update --minor
# or manually
wp core update-db

Verify after upgrade:

wp core version
# expected: 7.0.1
wp eval 'global $wp_version; echo $wp_version . PHP_EOL;'
# expected: 7.0.1

⚠️ Why this pitfall is so stealthy: Object Cache Pro's default connection-pool timeout is 5s — fine for normal traffic. But under a brief Redis 502, the entire cron subsystem stalls for 30s. I didn't see it on my own site until 2026-06-11 because the site wasn't on 7.0 yet; once 7.0 shipped the combination of Object Cache Pro 1.21+ + traffic peak triggered it for two production sites I follow.

💣 Pitfall 5: Redis full → all transients fall back to `wp_options`, hit-rate collapses silently

The scariest production incident this month: Object Cache Pro configured with maxmemory-policy=allkeys-lru. When Redis hits its 6GB limit, new writes evict old keys — that's expected. **But transients also fall into Redis**, and when Redis restarts or saturates, the cache layer enters graceful degradation: every get_transient/set_transient call now writes through to wp_options. **No alert fires.**

# Symptom:
wp transient get my_key
# (bool) false   # looks like a cache miss
# but the key SHOULD exist

Why? Redis Object Cache Pro 1.21+ introduced a parameter redis_cache_fallback_to_db (default true): short Redis blips degrade to wp_options transparently. Good for fault tolerance; terrible for observability.

# Inspect object-cache debug log
tail -f wp-content/object-cache.php
# Look for:
# Redis not available, falling back to internal cache (3x in 60s)

Without this signal, you never know degradation is happening.

Fix paths:

// wp-config.php — option A: disable the silent fallback
// Forces a real error if Redis is unavailable.
define('WP_REDIS_DISABLE_DB_FALLBACK', true);

# Option B: add Redis monitoring (recommended)
redis-cli info memory | grep used_memory_human
# used_memory_human:5.74G  <-- already near 6GB ceiling

# Option C: tune Redis eviction
redis-cli config set maxmemory-policy 'allkeys-lru'
redis-cli config set maxmemory '6gb'

⚠️ **Critical trade-off**: WP_REDIS_DISABLE_DB_FALLBACK = true causes set_transient() to throw a fatal error if Redis is genuinely down. Only enable this when Redis is fronted by Sentinel/Cluster, not standalone.

🛡️ Golden config on 7.0: wp-config.php x4 + object-cache.php x3

// wp-config.php — minimum viable production config for the task + cache layer

// 1. Cron single-flight lock
define('WP_CRON_LOCK_TIMEOUT', 60);

// 2. Don't spawn cron from the front-end (REQUIRED to pair with system crontab!)
define('DISABLE_WP_CRON', true);

// 3. Optional: disable Redis silent DB fallback
define('WP_REDIS_DISABLE_DB_FALLBACK', false);  // change to true with Sentinel/Cluster

// 4. 7.0.1+ parses retry-after headers automatically (Trac #62384)
// No manual config needed.

Object Cache Pro 1.21+ via wp-content/object-cache.php:

// 5. Cron lock prefers Redis
$redis_cache_cron_lock = true;

// 6. Transients route to specific Redis groups
$redis_transient_groups = ['default', 'wc_sessions', 'popularity'];

// 7. Failure hook — wire to your alerting
add_action('redis_cache_failure', function($error) {
    error_log('[Redis cache failure] ' . $error);
    // Slack / Sentry / email
});

📋 5-Item Production Verification Checklist

After upgrading to 7.0.1, run this:

# 1. Cron lock is operational
wp eval '
echo defined("WP_CRON_LOCK_TIMEOUT") ? WP_CRON_LOCK_TIMEOUT : "NOT_DEFINED";
echo PHP_EOL;
'
# Should print: 60

# 2. Scheduled publish works
wp post create --post_type=post --post_title='cron test' --post_status=future \
  --post_date='2026-07-15 11:00:00'
# 10 min later:
wp post list --post_status=publish | grep "cron test"

# 3. Object cache hit-rate
wp eval '
$obj = wp_cache_get( "stats", "object_cache_stats" );
if ( ! $obj ) return "no stats yet";
print_r( $obj );
'
# hits > 100 and misses < hits

# 4. Transients live in Redis
redis-cli keys '_transient_*' | head -10
# Non-empty output expected

# 5. wp_options autoload footprint
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'"
# Healthy range: < 4MB

All 5 pass → production-ready. Otherwise, revisit the matching section.

🧠 FAQ

Q: WP-Cron slows down the front-end — does it?

A: Not since 7.0. Cron spawn is wp_remote_post non-blocking; the front-end returns immediately. The one exception is the Trac #62757 race condition under 7.0.0 + Redis 502 — fixed in 7.0.1.

Q: If I disable WP-CRON but forget the system crontab, do tasks disappear?

A: No — they're still serialized in wp_options.cron. They just never fire. Setting up the system crontab later causes them to backfill via wp cron event run --due-now.

Q: What's the difference between Transients and wp_cache_*?

A: set_transient() is the public WordPress API — it picks Object Cache (Redis) or wp_options based on whether external cache is enabled. wp_cache_set() calls Object Cache directly with no wp_options fallback. Application code prefers transients (portable across single-site, Multisite, and clustered setups). Framework/library code uses wp_cache_* for precision.

Q: Risk of staying on 7.0.0 vs upgrading to 7.0.1?

A: Trac #62757 — only triggers on 7.0.0 + Object Cache Pro 1.21+ + peak traffic. Lower-stakes sites won't notice. But 7.0.1 ships automatic minor updates since 2026-05-15, so most installs are already on 7.0.1.

Q: Can I replace WP-Cron entirely with Linux cron?

A: Yes via wp cron event run --due-now. But most plugins register hooks on WP-Cron (Yoast SEO sitemap, Akismet, WP Crontrol) — those stop working without the WP layer. Only recommended when you have the full hook inventory documented.

📚 What's next

The next article in this series is **WP-Cron observability**: how to use wp cron event list --format=json + a Slack bot to alert on missed schedules, so you never see a hook silently failed for 3 days.