← All posts

Is My Object Cache Working?

By Nawawi Jamili · 26 October 2026 · 3 min read

You installed Docket Cache, and your site feels a little faster. But how do you know the object cache is really working? This post shows four simple ways to check, from the easiest to the most technical, and what to look at when something is wrong.

1. The Overview screen#

Open Docket Cache > Overview in your WordPress admin. This is the quickest check.

Look at these lines.

• Object Cache Stats shows how much data is in the cache, and in how many files. On the test site above, it is 332K in 70 files.
• Object OPcache Stats shows how many of those cache files OPcache keeps in memory. OPcache makes them faster to read.
• Drop-in File shows /wp-content/object-cache.php. This is the file that connects WordPress to Docket Cache.

Now open a few pages of your site, and then reload the Overview screen. If the numbers go up, Docket Cache is working.

On a site with many cache files, the Overview screen may show "No Object Cache Files" for a short time. The numbers come back by themselves within a few minutes.

2. Site Health#

WordPress has its own check. Open Tools > Site Health, then the Passed tests list. When an object cache is running, you see this line.

A persistent object cache is being used

"Persistent" means the cache is kept between page loads. Without an object cache, WordPress keeps its cache only until the page has loaded, and then starts again from nothing on the next page.

3. WP-CLI#

If you use WP-CLI, Docket Cache adds a few commands to wp cache. This one shows the status.

wp cache status

---------------:--------------------------------
Cache Status   : Enabled
Cache Path     : /wp-content/cache/docket-cache
Cache Size     : 331K
---------------:--------------------------------

The WP-CLI command that comes with WordPress tells you which object cache is in use.

wp cache type

docket-cache (v26.04.11)

4. Save a value, then read it back#

This is the most direct test. Each WP-CLI command runs as its own request, so you can save a value in one command and read it in the next.

wp cache set blog-test hello blog-check 300
wp cache get blog-test blog-check

Success: Set object 'blog-test' in group 'blog-check'.
hello

If the second command prints hello, the value was kept between the two requests. That is exactly what an object cache is for. Without one, the second command cannot find the value and shows an error.

Remove the test value when you are done.

wp cache delete blog-test blog-check

Hits and misses#

A hit means WordPress asked the cache for something and found it. A miss means it was not there, so WordPress had to ask the database. In one WP-CLI request on our test site, WordPress made 242 hits and 7 misses. A good object cache has many more hits than misses.

If you use the Query Monitor plugin, its Overview panel shows the hit rate for each page. To see what Docket Cache saves and reads in detail, turn on the Cache Log option in Docket Cache > Configuration. The Admin Interface page explains the log.

When it is not working#

If the numbers on the Overview screen stay at zero, or Site Health does not list the object cache, check these.

1. The drop-in file is missing. The file wp-content/object-cache.php must exist. If the Overview screen shows it as missing, click Enable Object Cache under Actions.
2. The delay file is still there. If the file wp-content/.object-cache-delay.txt exists, delete it. Docket Cache normally removes it by itself a few seconds after you activate the plugin.
3. The cache is turned off in wp-config.php. If you see "The Object Cache feature has been disabled at runtime", the DOCKET_CACHE_DISABLED constant is set to true in your wp-config.php file. Remove that line.
4. Another object cache plugin is active. Only one plugin can own object-cache.php. If you used Redis or Memcached before, turn that plugin off first.

The FAQ has more answers, and you can always ask on the support forum.