Tasks

Tasks are a one-to-one mapping of the scheduled tasks configured in your application.

For each task, we will track the

Command; whether that be an Artisan command, job, shell command, or closure,
Configured schedule, translated for convenience
When the task is next due
When the task was last updated
Task-specific configuration such as whether the task is allowed to overlap, run in maintenance mode, on one server, in the background, or has a truth test constraint.

Dashboard

The current time - in the application's timezone - next run time, and run late time - in browser-local timezone - as well as the configured cron schedule are displayed.

Like the project dashboard, the task dashboard will isplay metrics and insights for an individual task. This will show the total number of executions, average runtime, memory usage, and raised alerts over the preceding 30 days.

The execution history is time-limited based on your team's plan, however the data presented is identical.

For each execution, you will be able to see:

The name of the server
The local IP address of the server
The environment that the task ran in
The exit status of the task
The started and finished time
The memory consumed
The total runtime
The execution status

Tasks that were skipped due to the presence of a truth test constraint will show as such, and will not have any start or finish time, memory, or runtime data associated.

Settings

Not all tasks are created equal.

Tasks that run once a week, or once per month are likely to take more time to run than those that are scheduled to run daily, hourly, or every five minutes.

To that end, thenping.me provides some configuration options for runtime.

Warn if late

A number of minutes that we allow as a grace period after which we consider your task to be missing.

Allowed run time

Reporting tasks that run infrequently are typically responsible for running large queries, and aggregating lots of data. This, naturally, leads to tasks that can take longer to run and is indeed expected behaviour.

Configure the number of minutes we should wait before considering the task to be failing.

Consecutive failures threshold

For tasks that run more frequently, it may not be as critical that each and every execution is on time, completes successfully, or within a given runtime allowance.

To account for this, you may specify a threshold for consecutive failures that must breached before we raise an alert that it is missing.

For example, if you were to configure a consecutive failure threshold of 3, we will raise an alert on the third failure.

Legend

For each task, there are a series of icons that identify different components of its configuration.

May overlap Should this task run longer than it's configured interval, it is possible that it can be running multiple times simultaneously.

Not in maintenance mode This task will not run if you have run artisan down in your application.

On one server This task has been configured to run on one server only.

Runs in background This task has been configured to run in the background, so it will not delay the start of other tasks on the same execution schedule.

Task is filtered This task may be skipped, subject to the result of a truth-test constraint at runtime.

Status

A task can exist in one of six states:

Pending

We are waiting for your task to ping for the first time.

Running

We have received a start ping, indicating that your task is currently running.

Passing

Your task is currently running on schedule.

Missing

Your task was expected to send a start ping, but it has not been received within the allowed grace period.

Failed

We received a start ping on schedule, however, your task threw an exception and reported that it had failed.

Failing

We received a start ping on schedule, however, your task has not sent the finish ping within the runtime allowance.