Action Scheduler: a traceable WordPress job queue that ships inside your plugin

An action hook that can be delayed, repeated and given its own payload

The core idea is small enough to state in one line: Action Scheduler works by triggering an action hook to run at some time in the future, and each hook can be scheduled with unique data so the callback can operate on that data, and scheduled to run on one or more occasions. The README puts it as an extension to `do_action()` that adds the ability to delay and repeat a hook.

That framing explains why it exists. WordPress has hooks, and hooks are the wrong shape for work that should happen later: a plugin that needs to retry a failed webhook, send a scheduled receipt, or reconcile a subscription tomorrow has no good way to express that with `do_action()`, because the call runs immediately or not at all. Action Scheduler adds the missing time dimension and keeps the familiar hook mechanism underneath.

The audience is plugin and theme authors. The project description says it is specifically designed for distribution in WordPress plugins, and the README repeats that it is specially designed to be distributed in WordPress plugins, with no server access required. That constraint drives every design decision. A library that assumes a shared host with no shell access cannot use a resident daemon, a message broker, or a cron entry written into crontab, so it runs the work inside the WordPress request cycle and persists the queue in the database.

If you are building a WordPress plugin with a queue of more than a handful of jobs, this is the piece that turns those jobs from fire and forget calls into something you can retry and audit.

The queue is PHP classes and an API file, with a deprecated folder for old calls

The repository layout is where the internal shape shows. At the top level sit action-scheduler.php, functions.php, a classes directory, a lib directory, a deprecated directory, a docs directory and a tests directory, alongside composer.json, composer.lock, package.json, changelog.txt, readme.txt, phpcs.xml and codecov.yml.

The classes directory holds the implementation, the lib directory holds the framework facing pieces, and functions.php is the procedural API that plugin code actually calls. The API reference at actionscheduler.org is described as a complete reference guide for all API functions, which is the surface you will spend your time in.

The deprecated directory is the most informative entry for anyone planning an upgrade. Deprecated code is kept in the repository rather than deleted, so the library can keep old call signatures working while pointing developers at the replacement. For a plugin shipped to thousands of sites, where your users do not upgrade in lockstep with you, that pattern matters more than it looks: it is the difference between a major version bump breaking installs and a deprecation notice appearing in a log.

The tooling tells you about the quality bar. phpcs.xml configures the coding standard checks, codecov.yml configures coverage reporting, and the tests directory holds the test suite. The presence of AGENTS.md, CLAUDE.md and RELEASING.md in the root also shows a deliberate process around agent assisted work and releases, with RELEASING.md being the natural place to look for how a version is cut.

Installing it means shipping it inside a plugin, not running a service

There is no install command in this repository, and the documentation is the install instructions. The README points to the usage guide at actionscheduler.org for instructions on installing and using Action Scheduler, and the package is distributed through the WordPress plugin ecosystem, with the project configuration carrying a wp_org_slug of action-scheduler for both the config and the woorelease blocks.

For a plugin author, the shape of the installation is therefore a dependency inside your own plugin directory, where the scheduled actions then run in the context of the WordPress install that hosts it. That is the whole point of the no server access requirement: a shopper's shared hosting package is the target environment, and anything that needs a process running outside PHP is off the table.

Building a distribution archive is a separate concern, and the package.json build script shows what it involves. It installs production dependencies only, then packages the result as a zip through the composer archive command and runs a postarchive step:

    "build": "composer install --no-dev && npm install --only=prod && composer archive --file=$npm_package_name --format=zip && npm run postarchive",

The postarchive script unpacks the archive into a directory, zips that directory again and removes the temporary files, which is the trick for producing a plugin zip with a single root folder inside it. The engines block sets the toolchain floor for the build itself, requiring Node 16 or newer and npm 8 or newer:

  "engines": {
    "node": ">=16.0.0",
    "npm": ">=8.0.0"
  }

Those engine constraints apply to contributors building the library, not to the sites running it, which is worth keeping in mind when you read the requirement as a plugin author.

Two documented runners: the WP Cron queue runner and WP CLI

How the queued actions actually get executed is the part that decides whether the library fits your site. The documentation lists a guide to background processing at scale for running Action Scheduler at scale via the default WP Cron queue runner, and a separate WP CLI guide for running Action Scheduler at scale via WP CLI.

Those are two different approaches with different operational profiles. The WP Cron path piggybacks on the cron requests WordPress already triggers, so the work happens inside the site itself with no external process, at the cost of the timing being tied to when visitors hit the site. The WP CLI path is for sites where you can run a command yourself, which moves the execution out of the request cycle and gives an operator direct control over how much work runs at a time.

The distinction is the honest answer to the question of whether this library suits your infrastructure. If you have a shell on the server, the WP CLI route is the one that scales without waiting for traffic. If you are on shared hosting with a PHP only environment, the default cron runner is all you have, and the library is designed around that constraint.

A third element completes the picture, and it is the word traceable in the project description. The administration guide covers managing scheduled actions through the administration screen, so the queue is inspectable through the admin, not just through the database. Combined with the API reference, that gives you three surfaces: schedule work, inspect what is pending, and run it at a chosen pace.

The scale figures in the README come with a specific caveat

The README makes strong claims and then immediately narrows their meaning. It says that every month Action Scheduler processes millions of payments for Subscriptions, webhooks for WooCommerce, as well as emails and other events for a range of other plugins. It says it has been seen on live sites processing queues in excess of 50,000 jobs and doing resource intensive operations like processing payments and creating orders, at a sustained rate of over 10,000 per hour without negatively impacting normal site operations.

Then the qualifier, which is the part a careful adopter should notice: this is all on infrastructure and WordPress sites outside the control of the plugin author. The library is not a managed service. Those queues were run by people who operate the site, and the figure that matters to you is not the headline number but how much of that work your own plugin is responsible for.

The caveat cuts both ways. It means the library is proven in environments you cannot control, which is reassuring for a plugin distributed to strangers. It also means the sustained rate is a property of that infrastructure, not a guarantee about your host.

The honest framing is that the design goal, as stated, is background processing of large sets of tasks on a site where the plugin author has no infrastructure of their own. If your plugin needs a handful of jobs a day, this is more machinery than the job requires. If it needs tens of thousands of deferred operations with a retry story, the machinery is the point.

Who maintains it, and what the release line looks like

Action Scheduler is developed and maintained by Automattic, with significant early development completed by Flightless. The README invites collaboration and says pull requests are welcome, pointing at the pull requests page on the repository.

The release history in the repository shows three minor version releases in 2026: version 4.0.0 on 2026-06-16, version 4.1.0 on 2026-08-05 and version 4.2.0 on 2026-09-16. The last push to the default branch, trunk, was on 2026-10-11. The README badge still points at a Travis CI build, and the repository has moved on to a GitHub Actions workflow in the .github directory, which is a small inconsistency in the documentation that has not been cleaned up.

The licence is GPL-3.0, and package.json records it as GPL-3.0+. That is the fact with the most practical weight for a plugin author. If you bundle Action Scheduler inside a plugin you distribute, the copyleft terms of the GPL apply to the combined work, so a proprietary plugin that vendors this library carries obligations it may not want. The alternative is to keep Action Scheduler as a separate plugin dependency, which is the arrangement the project description implies with its distribution model.

The project also ships a changelog.txt and a readme.txt, so a plugin author can check what changed between versions before deciding to require a minimum version in their own dependency list.

Editorial conclusion

Action Scheduler fits a plugin author who needs repeatable, inspectable background work on shared hosting where no daemon can be installed, and who is willing to treat the action tables as part of their own product. It does not fit a project that already runs a long lived worker and needs precise timing, because the documented runners are a cron driven queue and a WP CLI command, and neither is a resident process. Before adopting, read the administration guide and the API reference at actionscheduler.org, then check that your plugin's own release cycle can carry the four tables and the upgrade path the deprecated folder in this repository signals. The library is GPL-3.0, which matters if you intend to distribute it inside a proprietary plugin.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. woocommerce/action-scheduler on GitHub