--- title: Background Processing in WordPress Plugins Without Timeouts description: Build reliable background processing in WordPress plugins with bounded jobs, queues, locks, retries, idempotency, progress, and failure recovery. url: https://wpstack.online/blog/background-processing-wordpress-plugins date_modified: 2026-07-29 author: Aditya Bhimrajka language: en_US --- Imports, scans, exports, email batches, and API synchronization can quickly outgrow a normal WordPress request. Increasing the PHP execution limit may delay failure, but it does not create a reliable processing system. A dependable background process divides work into controlled jobs, persists progress, recovers after interruption, and prevents duplicate effects. It should continue when the administrator closes the browser and explain failures clearly. This guide is for WordPress product owners, developers, and agencies that need a repeatable engineering decision rather than a shortcut that works only on one installation. ## Turn One Long Operation into Bounded Jobs Do not ask one request to process an entire catalogue, media library, customer list, or remote dataset. Divide the operation into bounded jobs. A worker might process 100 records, one file, one API page, or several seconds of work before saving progress and releasing memory. The correct batch size depends on record complexity, database workload, network latency, and the minimum hosting environment the plugin supports. A batch that works on a dedicated server may time out or exhaust memory on shared hosting. Begin conservatively and tune with measurements. Record duration, memory use, query count, and failure frequency. Each job should have a clear input, cursor, and completion condition. ## Persist a Durable Cursor Progress must be stored in the database or another durable system. It should not depend on JavaScript state, an open browser tab, or a temporary response. A cursor identifies where the next batch should begin. It may be a record ID, page token, timestamp, file offset, or ordered combination of fields. Persist the cursor only after the current batch completes successfully. Saving it too early can skip unfinished records, while saving it too late can repeat unnecessary work after a crash. Cursor design also needs stable ordering. Offset pagination can become inconsistent when records change during processing. A unique identifier or provider continuation token is often safer. The progress screen should read this durable state so refreshing the page does not restart or lose the operation. ## Pass Identifiers, Not Large Objects Queue payloads should remain small, stable, and safe. Pass record IDs, site IDs, job IDs, and other identifiers instead of serializing complete WordPress objects, API responses, or large arrays. Load the latest record state when the worker starts because queued data may be stale. Do not place passwords, API keys, authorization headers, or personal records in job arguments. Retrieve protected secrets only when needed. ## Make Every Job Idempotent Queues retry, workers crash, requests overlap, and administrators click twice. A reliable job must tolerate repeated execution. Idempotency means that running the same intended operation more than once produces the same final result. Use stable idempotency keys, unique constraints, processed markers, and compare-before-write logic. For an email batch, record whether a message was already sent for the job and recipient. For an import, identify records through a stable source key. For API synchronization, compare remote and local versions before applying an update. Do not rely only on checking for a record and then inserting it. Two workers may pass that check simultaneously. A database-level unique constraint provides stronger protection. ## Use Locks and Idempotency Together A lock and an idempotency control solve different problems. A lock reduces the chance that two workers process the same job concurrently. Idempotency protects correctness when the lock expires, a worker crashes after writing, or the queue delivers the job twice. Locks should have an owner, acquisition time, and expiry. A permanent lock can leave a job stuck forever after an unexpected failure. Even with locking, every important side effect should remain idempotent. ## Choose Scheduling According to the Guarantee ![Comparison of WP-Cron, system cron, and dedicated queues for scheduling background jobs in WordPress plugins.](https://wpstack.online/wp-content/uploads/2026/08/Comparison-1024x683.webp)Image Source: AI-generated visual by Wpstack WP-Cron is triggered by site traffic. A due event runs when WordPress receives a later request and starts the scheduler. This suits many cleanup, maintenance, and low-urgency tasks, but it is not a precise delivery guarantee. Low traffic can delay jobs, while weak locking can create overlapping attempts. A system cron can invoke WP-Cron predictably and remove the dependency on visitor traffic. A dedicated queue such as Action Scheduler provides richer job tracking, claims, retries, and administration for plugin workloads. The correct choice depends on timing requirements, job volume, hosting control, and support expectations. Our guide to [WP-Cron versus system cron](/blog/wp-cron-vs-system-cron/) explains the operational trade-offs. The [WordPress Cron Handbook](https://developer.wordpress.org/plugins/cron/) and [WP-Cron scheduling](https://developer.wordpress.org/plugins/cron/understanding-wp-cron-scheduling/) can support the internal review of recurrence, unscheduling, and callback design. ## Design the Failure Experience A job should not disappear into an unknown failed state. Store a sanitized error category, attempt count, last attempt time, next retry time, and last successful cursor. Avoid storing complete API responses, personal data, credentials, or unrestricted stack traces in administrator-facing logs. Classify failures as transient or permanent. Network timeouts, rate limits, and temporary provider outages may justify retries with exponential backoff. Invalid input, revoked authorization, or unsupported formats usually require intervention. Set a maximum number of automatic retries. After that limit, move the job to a failed state that an authorized administrator can inspect. Provide safe retry, cancel, and resume actions protected by capabilities and nonces. Retrying should continue from durable state and reuse the same idempotency controls. ## Make Cancellation and Resume Predictable Cancellation should prevent new batches from starting while allowing the current bounded batch to finish safely. Check cancellation between records or controlled steps, then persist a clean stopping point. A resumed job should continue from its last successful cursor instead of beginning again unless the administrator deliberately requests a full restart. Progress must come from durable state rather than a browser connection. Closing a tab must not abandon the operation. ## Test Worker Crashes Deliberately Do not test only successful completion. Simulate a crash before processing, after the first write, before cursor persistence, after cursor persistence, and before the job is marked complete. Confirm that retries do not duplicate records, payments, emails, exports, or notifications. Test overlapping workers, expired locks, lost queue claims, temporary remote failures, invalid records, and administrator cancellation. ## Implementation Checklist Split work into bounded batches. Persist cursors after successful work. Pass identifiers instead of large objects or secrets. Use locks and idempotency keys. Classify transient and permanent failures. Apply bounded retries and exponential backoff. Expose progress, retry, cancel, and resume controls. Test worker crashes between important state changes. ## Build Reliable Background Processing for WordPress Plugins Contact WPStack to improve imports, exports, scans, email batches, API synchronization, and other long-running operations with bounded jobs, durable progress tracking, safe retries, predictable cancellation, and clear failure reporting. WPStack provides custom WordPress [plugin development](https://wpstack.online/custom-plugin-development/) and background-processing services to help businesses build production-ready workflows with persistent cursors, idempotent jobs, secure queue payloads, controlled locking, retry backoff, and reliable processing that continues after the browser closes. Planning a new background workflow or fixing unreliable scheduled tasks in an existing plugin? Request a custom WordPress plugin assessment with WPStack and discuss your requirements with an experienced development team. ## Frequently Asked Questions **Can AJAX Be Used for Background Processing?** AJAX can coordinate batches while a browser remains open, but it is not durable background execution. Use a queue or scheduled worker when work must continue independently. **How Large Should a Batch Be?** Choose a size that stays comfortably below memory and execution limits on the minimum supported hosting environment. Begin conservatively and tune it with measurements. **What Is an Idempotency Key?** It is a stable identifier for one intended operation. The system records it so repeated delivery or execution does not create duplicate effects. **Should Failed Jobs Retry Forever?** No. Use bounded attempts, backoff, and a failed state that an administrator can inspect and deliberately retry. Planning a production plugin? Review what makes a WordPress plugin production-ready, browse the WPStack plugin directory, or discuss a custom build.