Background processing
Imports, exports, and other longer-running actions in GravityKit products can run in the background when they need more time to finish.
Instead of trying to complete everything in a single page load, the job is queued and processed behind the scenes. This helps larger actions finish more reliably without forcing everything to happen in one request.
When you will see it #
Background processing is typically used for things like:
- importing entries
- generating export files
- running scheduled jobs
- processing larger batches of data
You usually do not need to do anything special. Start the import, export, or other action, leave the page if you want to, and check back later if you want to confirm that it finished.
Settings related to background processing #
A number of settings options are available under GravityKit > Settings > GravityKit > Technical ย menu.
Enable Background Processing | On by default | Allows GravityKit products to process long-running tasks in the background |
Show Background Jobs ย | Off by default | Adds a Background Jobs page under the GravityKit menu for access to the past, current and scheduled activities. |
Loopback URL Override ย | Empty by default | Background jobs rely on the site being able to send a request to itself in order to start or continue processing. By default, that request uses your normal site URL. This setting lets you replace it with a different URL if the server cannot reach the public site URL from inside the hosting environment. |
Troubleshooting #
If background jobs are not starting or finishing, check the following.
Go to Tools > Site Health > Info ย ย and look for the GravityKit Background Processing ย section. This shows whether the scheduler has a working execution path and will indicate what is wrong.
Jobs don’t run
Background jobs are processed by a queue runner that sends HTTP requests back to the site. If the server cannot make these loopback requests, jobs will stay stuck.
Common causes:
- basic authentication or password protection on the site
- maintenance mode
- a security plugin blocking internal requests
- firewall or WAF rules
- proxy or load balancer configuration
- DNS or SSL issues preventing the server from resolving its own URL
To fix:
- temporarily disable basic authentication or password protection
- turn off maintenance mode
- check security plugin settings for blocked internal requests
- ask your host whether loopback or self-requests are being blocked at the server or firewall level
If the server can reach itself but at a different URL than your site’s home URL (common with reverse proxies, load balancers, or containerized hosting), ask your host for the correct internal URL and add it under settings.
If loopback cannot be fixed at all, adding define( 'ALTERNATE_WP_CRON', true ); ย ย to wp-config.php ย can work as a last resort. It processes cron tasks inline during page loads, which is slower but functional.
Jobs don’t run on time
Scheduled jobs may run later than expected on low-traffic sites. Background processing is triggered when someone visits the site – if no one visits, scheduled jobs wait until the next page load.
If you need jobs to run closer to their scheduled time, use an external service like FastCron to visit your site at a regular interval. This ensures background processing is triggered even when there are no visitors.