Tasks

• Tasks

• Introduction

• Schedule

• Context

• Execution

• Statistics

Introduction

Scheduled tasks are wrappers around Commands, providing information about a specific execution schedule, execution context and execution parameters.

Anything you've defined (and not explicitly excluded) in your application's scheduler will be imported, giving you control to tweak any of their settings.

{info} Tasks imported from your codebase are not fully editable by default. You need to explicitly specify that you want to edit some of their settings in order to do so.

You can exclude tasks from tracking in two ways:

1. By excluding the task's handler class in the discovery settings
2. By using Cronboard::dontTrack() (see below for an example)

Excluding tasks from tracking directly inside your application's scheduler:

use Cronboard;

class Kernel extends ConsoleKernel
{
    protected function schedule(Schedule $schedule)
    {
        Cronboard::dontTrack($schedule)
            ->command(AnyCommand::class)->everyThirtyMinutes();
    }
}

Schedule

The dashboard provides full control for editing your task's schedules, and supports most options and controls made available by Laravel itself. It provides an additional layer of validation that would prevent a number of errors potentially occuring if you were to make the schedule changes manually in code.

In addition to providing a completely custom schedule definition you're also given the ability to quickly enabled / disable tasks, or the schedule immediate exections. This would be especially useful in cases where a task is not working correctly, or where you'd want to re-run one without having to go through the process if editing you codebase back and forth.

Context

In addition to editing the schedule of a task you can alter its execution context as well. This includes environment variables set on the server, but also Laravel's own configuration settings. This can be especially useful for testing misbehaving tasks.

{warning} Note that Laravel's environment variables are cached on production environments and may not be overridden if that's the case. It is recommended you use the configuration overrides in scenarios like that.

Execution

You can hook into the instantiation process of each task, by providing custom parameters. In the case of console commands this will allow you to edit the command line parameters passed to the command, as part of this scheduled task.

Invokable objects allow for even more control, as you are able to specify what parameters to use to instantiate the object, but also what parameters to pass to its __invoke() method.

When making changes to any of these parameters and settings the dashboard will provide an overview of how these will be reflected in code, during the task's execution process.

Statistics

As part of each task Cronboard will track information such as how much memory was used and how long it took to execute the task. These are also aggregated on task level to show the averages between all executions.

In many cases it will be useful to track any number of custom variables. Cronboard allows you to du just that using Cronboard::report(). You can attach any number of key-value information to an execution like so:

use Cronboard;

// ...
// 
public function handle()
{
    Cronboard::report('Total pending orders', 3);
    Cronboard::report('Total emails sent', 42);
}

This will then be surfaced within the executions results .

{info} Only scalar values are supported. If you try to report anything else it will be ignored.