Running WP-Cron Properly on a Kinsta WordPress Multisite

On Kinsta, scheduled WordPress tasks are normally triggered by a server level cron that calls wp-cron.php at fixed intervals.

That works well for single site installations.

For WordPress Multisite, applications that depend on reliable background processing often need a different approach. A single wp-cron.php request does not always execute scheduled events for every subsite in a predictable way.

For systems that run queues, scheduled integrations, or time sensitive jobs, the correct method is to use WP-CLI and explicitly run cron for each site in the network.

This guide describes a production safe configuration for Kinsta.

How cron works on Kinsta

Each WordPress environment runs inside a container. You have:

SSH access
WP-CLI available
access to the container crontab

By default Kinsta registers a cron that periodically requests:

https://localhost/wp-cron.php

This triggers WordPress cron for the primary site.

For multisite networks, this does not guarantee consistent execution for every subsite.

When you should change the default behavior

You should replace the default trigger if:

the site is a multisite network
you run background queues
scheduled jobs must run on time
the system behaves like an application rather than a content site

Step 1. Disable request based cron

In wp-config.php:

define('DISABLE_WP_CRON', true);

This prevents cron from running during frontend requests and avoids unnecessary PHP worker usage.

Step 2. Create a multisite cron runner

Create a shell script inside the container, outside the public web directory.

Example:

#!/bin/bash
export PATH="/usr/local/bin:/usr/bin:/bin"

cd /path/to/wordpress/root || exit 1

wp site list --field=url | while read -r url; do
  wp cron event run --due-now --url="$url" --quiet || true
done

Why this approach is correct on Kinsta

WP-CLI is available inside the container
Each subsite runs in its own context
Failures on one subsite do not stop the loop
No external HTTP requests are required

Make the script executable:

chmod +x /path/to/run-multisite-cron.sh

Step 3. Register the cron inside the container

Edit the crontab:

crontab -e

Add:

MAILTO=""
*/5 * * * * /path/to/run-multisite-cron.sh >/dev/null 2>&1

Important

Disable or comment out the default Kinsta cron that calls wp-cron.php. Only one cron trigger should exist.

Running both will cause duplicate execution.

Step 4. Optional logging during setup

For verification:

*/5 * * * * /path/to/run-multisite-cron.sh >> /path/to/cron.log 2>&1

Then inspect:

tail -f /path/to/cron.log

After confirming correct execution, output can be redirected to /dev/null.

Verifying that cron works

You can manually execute the script through SSH. A correct setup will:

process due events for multiple subsites
return immediately when no events are scheduled
not depend on web traffic

This confirms that the server cron is functioning.

A common source of confusion

If output shows database errors related to missing custom tables, the cron system is working.

This indicates an application level issue such as:

a plugin activation routine that did not run network wide
a missing database migration
a subsite that has not been initialized

Cron is only the trigger.

Recommended execution interval

For most production multisite systems on Kinsta:

Every five minutes is appropriate.

More frequent execution should only be used for real queue processing.

Final configuration

wp-config.php

define('DISABLE_WP_CRON', true);

container crontab

MAILTO=""
*/5 * * * * /path/to/run-multisite-cron.sh >/dev/null 2>&1

cron runner

A WP-CLI script that loops through subsites and runs due events.

Result

With this configuration:

scheduled tasks run reliably for every subsite
background processing becomes deterministic
PHP workers are not consumed by request based cron
the system behaves like an application platform

This is the correct approach for running WordPress Multisite with application style workloads on Kinsta.