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.


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.


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.


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.


A task can exist in one of six states:

We are waiting for your task to ping for the first time.
We have received a start ping, indicating that your task is currently running.
Your task is currently running on schedule.
Your task was expected to send a start ping, but it has not been received within the allowed grace period.
We received a start ping on schedule, however, your task threw an exception and reported that it had failed.
We received a start ping on schedule, however, your task has not sent the finish ping within the runtime allowance.