Repeated remote lookups can mean that cron, wp-admin and the front end disagree about where reusable data lives. I follow one transient from a write in one request to a read in another. That catches values which disappear at the end of an admin or scheduled request despite the site having a persistent object cache.
Temporary does not mean request-local
A WordPress transient is cached data with an expiry. It might represent a remote version check or a derived result which is safe to reuse. It is different from a value which deliberately exists only during one page request.
With a persistent object cache, transients can live in that cache rather than the options table. Looking for them only in the database can therefore lead me to the wrong conclusion. The WordPress Transients API documentation also makes clear that expiry is a maximum lifetime: a transient can disappear earlier, so the code still needs a regeneration path.
Separate reusable data from personalised responses
Bypassing a full-page cache for logged-in visitors is sensible. It does not follow that every piece of reusable background data must also be discarded at the end of an admin request. Those are separate decisions.
I narrow the persistent allowance to the groups and values which should be shared, retaining their expiry, encoding rules, size limits and exclusions. That avoids turning a targeted fix into an indiscriminate decision to persist all admin state.
Reads, writes and deletes need one policy
A scheduled job writing to one store while the front end reads another is an obvious problem. A subtler version is an invalidation reaching Redis while an in-memory copy survives inside the current request. I check all three operations together and make the intended behaviour explicit.
False values deserve care too. If the API uses false to mean a miss, the application needs a way to distinguish a legitimate cached result from “nothing stored”. Otherwise a negative result can accidentally trigger the expensive work every time.
Follow one real lookup
I test an actual transient from creation to reuse: one admin request creates it, a later request reads it, cron updates it, and deletion removes it where every relevant caller looks. I record remote-call counts as well as page timings. A faster second page is encouraging; evidence that the duplicate call stopped tells me why.
This kind of fix often improves the parts of WordPress editors use all day, even when the public homepage was already fast. It is a good reminder to profile the admin workflow rather than judging the whole site from a cached visitor page.