# laravel-short-schedule: artisan commands on a sub-minute frequency

> spatie/laravel-short-schedule runs Artisan commands every second or every half second, using a separate long-running ReactPHP process rather than Laravel's own scheduler, so short tasks never collide with the regular schedule. Each command runs as its own background process, and the worker can be given a lifetime so leaking commands are recycled.

**spatie/laravel-short-schedule** — Schedule artisan commands to run at a sub-minute frequency

- Repository: https://github.com/spatie/laravel-short-schedule
- Website: https://freek.dev/1683-a-package-to-schedule-artisan-commands-at-sub-minute-frequencies
- Stars: 659 · Forks: 53
- Language: PHP
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/spatie-laravel-short-schedule

## Laravel's scheduler stops at one minute, and this goes past it

Laravel's native scheduler allows you to schedule Artisan commands to run every minute. The gap this package fills is the one below that, and the README is explicit that if you need to execute something with a higher frequency, for example every second, this is where to look. The audience is therefore narrow and technical: an application that genuinely needs a command to run every second or every half second, rather than one that could get away with a minute. The use case that comes to mind is a long-running poll of an external API, a device heartbeat, or a cache warmer, and the design decision that follows from it is that such a task is not the kind of thing you want inside the same process as your minute-level cron. The package is MIT licensed, published on Packagist as spatie/laravel-short-schedule, and the 1.x line is current, with 1.7.0 released on 2026-03-26 and the last push on 2026-06-03.

## Two ways to declare the schedule: a facade or a kernel method

You can register short scheduled commands in two places, and the README shows both. The first is the ShortSchedule facade, used in your routes/console.php file:

```php
use Spatie\ShortSchedule\Facades\ShortSchedule;

ShortSchedule::command('artisan-command')->everySecond();
```

The second is a method named shortSchedule in your app/Console/Kernel.php, which receives the ShortSchedule instance directly:

```php
protected function shortSchedule(\Spatie\ShortSchedule\ShortSchedule $shortSchedule)
{
    // this artisan command will run every second
    $shortSchedule->command('artisan-command')->everySecond();
    
    // this artisan command will run every second, its signature will be resolved from container
    $shortSchedule->command(\Spatie\ShortSchedule\Tests\Unit\TestCommand::class)->everySecond();
}
```

Both forms support the same frequencies. everySecond() schedules a command every second, everySeconds(30) takes an explicit count, and everySeconds(0.5) goes below one second. Commands can be given by name or by class, and in the class case the signature is resolved from the container, which is what lets a constructor-injected command work without extra wiring.

## A separate ReactPHP process, one timer per command

The mechanism is described in a section called How it works, and the first decision is that the short-schedule:run command starts a single long-running process powered by a ReactPHP event loop. That process is entirely separate from Laravel's native scheduler, schedule:run, so short scheduled tasks never delay, or get delayed by, the regular schedule. Inside the loop, every scheduled command gets its own periodic timer, and when a timer fires the command is launched as an independent background process using the non-blocking start() method of the Symfony process component. The loop does not wait for that process to finish, it immediately continues handling the other timers. This is the part that makes the package behave differently from the obvious alternative, and it is worth stating plainly as a design consequence rather than a feature. Every tick is a new process start, so the cost of running every second is a process launch every second, not a resumed PHP runtime.

## What blocks the loop, and what does not

Not everything runs outside the loop, and the README is candid about the exceptions. A few things do run inside the loop itself and will block it when they are slow. The constraints you add, such as when and between, are evaluated on every tick, and so are any listeners for the events the package describes. The advice given is to keep those fast and to offload any heavy work to a queue. The distinction matters in practice. A command that takes thirty seconds to run does not hold up the other short scheduled tasks, because it lives in its own process, but a constraint callback that queries a slow service, or an event listener that does real work, will stall the whole loop and with it every timer on it. The README also notes the difference with the native sub-minute scheduler, which by default runs tasks sequentially in the foreground, where a single long-running task can delay every task defined after it. That is the concrete difference in approach between the two, and it is the reason to prefer one over the other.

## Shell commands, and the worker that has to keep running

The package also schedules plain shell commands, not only Artisan ones, using exec with the same frequency methods:

```php
ShortSchedule::exec('bash-command')->everySecond();
```

The operational side is the part that decides whether this is a good fit for your server. Installation is a single composer command:

```bash
composer require spatie/laravel-short-schedule
```

Then the worker is started with:

```bash
php artisan short-schedule:run
```

The README asks you to use a process monitor like Supervisor to keep this task going at all times, and to start it automatically when the server boots. It also says that whenever you change the schedule you should restart this command, which tells you something about the lifecycle: the schedule is read at startup, so a change to the frequency list is not picked up by a running worker.

## A worker lifetime for commands that leak memory

There is a mechanism for the classic long-running PHP problem, and it is a flag rather than a config file. To deal with commands that leak memory, you can set the lifetime in seconds of the short schedule worker:

```bash
php artisan short-schedule:run --lifetime=60 // after 1 minute the worker will be terminated
```

After the given number of seconds the worker and all its child processes are terminated, freeing the memory, and then Supervisor, or a similar watcher, brings it back. This is a blunt instrument on purpose. A command that leaks will be recycled on a fixed interval rather than accumulating until the process is killed by the operating system, and the cost of the approach is a brief gap in scheduling at each restart. If your commands are well behaved, leave the flag off and the worker runs until something else stops it.

## Documentation, tests and the shape of the package

The README points at three videos rather than at a long manual, one demonstrating the package, one going under the hood, and one showing how the package is tested, with the note that you can learn how to test ReactPHP powered loops from the last one. That last point is the one to pay attention to if you plan to write tests around scheduled behaviour, because a package that runs a background event loop is exactly the kind of thing that is hard to test without a documented approach. The videos are part of the Laravel Package Training. The repository is a conventional Spatie PHP package with a src directory, a tests directory, a composer.json, a phpunit.xml.dist, a .php_cs.php file for style, a CHANGELOG.md and a LICENSE.md. The release history runs 1.6.3 on 2025-04-09, 1.6.4 on 2025-07-28 and 1.7.0 on 2026-03-26. The project also carries the standard Spatie support material, links to their paid products and asks for a postcard, which is a reasonable signal about how a small commercial shop maintains its open source packages.

## Conclusion

laravel-short-schedule fits a Laravel application that needs a command to run every few seconds, for example polling a queue, refreshing a cache or checking a device, and that can afford one more supervised process on the server. It does not fit a workload where the sub-second timing matters more than isolation, since every run is a fresh PHP process rather than a resumed one. Before adopting it, decide how the worker will be supervised, since the README asks for Supervisor to keep it alive and to restart it on boot, set a worker lifetime if your commands leak memory, and keep the constraint callbacks and event listeners inside the loop fast, because those are the parts that run in the loop and can block it.

## FAQ

### How do I install laravel-short-schedule and start the worker?

Install it with composer require spatie/laravel-short-schedule, then start the worker with php artisan short-schedule:run. The README asks you to run that under a process monitor such as Supervisor so it keeps running and starts on boot, and to restart it whenever you change the schedule.

### How often can laravel-short-schedule run a command?

Every second with everySecond(), every given number of seconds with everySeconds(30), and below one second with everySeconds(0.5). Commands can be named Artisan commands or classes, in which case the signature is resolved from the container.

### How does laravel-short-schedule differ from Laravel's own sub-minute scheduling?

The native sub-minute scheduler runs tasks sequentially in the foreground, so one long-running task delays every task after it. This package runs each command as an independent background process from a ReactPHP event loop, so a slow command does not hold up the others.

### What can block the short schedule loop?

The constraints you add, such as when and between, are evaluated on every tick inside the loop, and so are the event listeners. The README advises keeping those fast and offloading any heavy work to a queue.

## Sources

- [License: MIT](https://github.com/spatie/laravel-short-schedule/blob/main/LICENSE)
- [Project website](https://freek.dev/1683-a-package-to-schedule-artisan-commands-at-sub-minute-frequencies)
- [README](https://github.com/spatie/laravel-short-schedule/blob/main/README.md)
- [Releases](https://github.com/spatie/laravel-short-schedule/releases)
- [spatie/laravel-short-schedule on GitHub](https://github.com/spatie/laravel-short-schedule)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spatie-laravel-short-schedule