WP-Cron Requirements for PetMatchPro Analytics #

Requires Preferred license. Applies to PetMatchPro 8.7.0 and later.

Starting with 8.7.0, PetMatchPro analytics relies on WordPress scheduled tasks (commonly called WP-Cron) to drain a small in-database queue of impression events once per minute. This article explains why, how to verify it is working, and what to do if your host has disabled WP-Cron.

Why Does PetMatchPro Need WP-Cron? #

Before 8.7.0, every page-load impression was written directly to the database during the visitor’s request. On hosts with LiteSpeed and Cloudflare in front of WordPress, those writes added up to 1.5 – 2.3 seconds per request – even though the actual database write took less than 100 milliseconds. The host stack itself was the cost.

8.7.0 decouples the visitor experience from the database write:

1. The visitor’s browser collects impressions as cards enter the viewport and fires them off via sendBeacon – non-blocking, fire-and-forget.
2. The server appends each batch to a queue option and returns in about 5 milliseconds of PHP work (the rest is unavoidable host-stack baseline).
3. A WordPress scheduled task runs once per minute, drains the queue, and bulk-inserts everything into the events table in a single SQL statement.

This means visitors never wait on analytics writes, and your dashboard is at most 60 seconds behind real time. The trade-off: if WP-Cron stops firing, the queue stops draining.

How to Check if WP-Cron Is Firing #

There are two easy ways to verify cron health on your site:

Option 1: PetMatchPro built-in tools (recommended) #

1. Go to PetMatchPro > Analytics tab.
2. Open the Analytics Queue Health accordion.
3. Read the three rows: queue depth, last flush, next scheduled.

On a healthy site, “Last flush” should show an age under 60 seconds and “Next scheduled” should show a time under 60 seconds. If either field shows a yellow “Cron may be broken” badge, follow the remediation steps below.

You can also run an active diagnostic from PetMatchPro > Tools > Cron Self-Test. The button schedules a one-shot test event 60 seconds in the future, polls for the result, and reports back within 2 minutes. See Queue Health and Tools.

Option 2: WP Crontrol plugin (third-party) #

If you want a more detailed view of every scheduled event on your site, install WP Crontrol (free). Once activated:

1. Go to Tools > Cron Events.
2. Look for the pmp_flush_impression_queue hook.
3. Confirm its “Next Run” timestamp is in the near future (within 60 seconds).
4. If “Next Run” shows “Now” but the timestamp is hours old, cron is not firing.

Common Reasons WP-Cron Fails #

• Host has disabled it. Some managed hosts set DISABLE_WP_CRON = true in wp-config.php and provide their own server-level cron replacement. Others disable it without providing a replacement at all – this is the most common cause of broken analytics.
• Very low traffic. WP-Cron is “pseudo-cron” – it piggybacks on visitor requests. If your site receives no traffic for an hour, no scheduled tasks fire during that hour. Most shelter sites have enough baseline traffic that this is not an issue, but it can affect off-hours measurements.
• Security plugin interference. Wordfence, iThemes Security, and similar plugins occasionally block wp-cron.php by default. Check their firewall logs.
• Hosting-level cron job pointing at the wrong URL. A real cron job that hits a stale or moved URL silently fails.

How to Fix It #

The recommended fix for any broken-cron host is to set up a real, server-level cron job that hits wp-cron.php once per minute. This bypasses WordPress’s pseudo-cron entirely and is more reliable on low-traffic sites.

If your host has a cron job UI #

Most managed WordPress hosts (Kinsta, WP Engine, SiteGround, Cloudways, etc.) expose a cron job UI in their control panel. Look for “Cron Jobs”, “Scheduled Tasks”, or “Task Scheduler”. Add a job with:

• Schedule: Every minute (* * * * *)
• Command: wget -q -O - https://your-site.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1 (replace your-site.com with your actual domain)

If you have shell access #

Edit your crontab with crontab -e and add:

* * * * * wget -q -O - https://your-site.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

If wget is not available, use curl:

* * * * * curl -s https://your-site.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Then disable WordPress’s built-in pseudo-cron #

Once your real cron job is firing, add this line to wp-config.php to keep WordPress from running its own per-request pseudo-cron:

define('DISABLE_WP_CRON', true);

Place it above the line that says /* That's all, stop editing! */.

What Happens if WP-Cron Is Broken? #

PetMatchPro detects this and falls back gracefully:

• If the queue has not been drained in 5 minutes and contains at least 100 entries, the next analytics request will drain it synchronously. This is slow (one request pays the full host-stack cost) but ensures no data is lost.
• If the queue grows past 5,000 entries (extreme worst case), the oldest entries are dropped to prevent the queue option from ballooning.
• The Queue Health card surfaces a yellow warning badge so operators see the problem.

Translation: analytics will keep working even on a host with broken cron, but page loads may be intermittently slower and the dashboard may lag behind real time. Fix cron for the best experience.

Verifying Analytics Is Working #

1. Visit a search page on your site (logged out, in an incognito window).
2. Scroll through several animal cards.
3. Wait 60-90 seconds.
4. Go to PetMatchPro > Analytics > Dashboard and confirm impression counts have increased for today.

If counts do not increase: check the Queue Health card first, then run the Cron Self-Test from the Tools tab.

Next Steps #

• Queue Health and Tools – Reading the health card and using diagnostic buttons
• Understanding PMP Analytics – What the dashboard measures
• Privacy and Data Retention – What is stored, what is not