> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Job Schedules

> Recurring and one-time schedules that create jobs when due

A **Job Schedule** registers a recurring cadence or a one-time future action. When a ticket asks for work on a repeating schedule - *"check disk space every Monday at 09:00"*, *"restart the worker every weekday at 07:30"*, *"every 15 minutes"* - 2501 doesn't run the job once; it registers a schedule. Each tick spawns a fresh [Job](/0.15/core-concepts/jobs) that follows the normal lifecycle.

Schedules are managed under **Job Schedules** in Command Center.

<Frame caption="Job Schedules: each row is a cadence. Each tick fans out into a normal Job with all the usual orchestration and reporting.">
  <img src="https://mintcdn.com/2501/kr0HtinaCJPsc_vr/images/job_schedules.png?fit=max&auto=format&n=kr0HtinaCJPsc_vr&q=85&s=95bf01387f562d3460aab1acf489fc8b" alt="Job Schedules" width="2880" height="1800" data-path="images/job_schedules.png" />
</Frame>

## How a schedule is created

Schedules are **registered automatically** when an incoming ticket describes a recurring action. The gateway detects the cadence in the ticket text and creates the schedule instead of a one-off job.

You don't create schedules manually in Command Center. The action of "make this recurring" comes from the ticket itself - usually a comment or a description like *"run this every Monday morning"*.

A single cadence can also name a **set of days**, such as *"every weekday at 07:30"*, *"every Monday and Wednesday at 10:00"*, or *"every weekend at 11:00"*. It registers as one schedule that runs on each of those days, not one schedule per day. The phrase still needs a recurring word like *"every"*: naming days alone (*"on Monday and Wednesday at 10:00"*) reads as one-off work, not a schedule.

## One-time future work

A request such as "restart nginx tomorrow at 15:00" creates a one-time schedule. At that time, the schedule creates a new [Job](/0.15/core-concepts/jobs), which plans and creates the [Tasks](/0.15/core-concepts/tasks) needed to perform the request. Work requested immediately can proceed separately.

A completed one-time schedule has no next run. Cancelling it before its start time prevents that job from being created.

## What you see for each schedule

| Field             | What it shows                                                                |
| ----------------- | ---------------------------------------------------------------------------- |
| **Cadence**       | The interpreted schedule (e.g. *"weekly, Mondays at 09:00 UTC"*)             |
| **Source ticket** | The original ITSM record that introduced the schedule                        |
| **Next run**      | When the next Job will spawn                                                 |
| **Run history**   | The Jobs that have fired from this schedule so far, each with its own status |
| **Status**        | `active` or `cancelled`                                                      |

## Managing a schedule

* **Pause / stop** a schedule from its detail page. Stopping it cancels future ticks but does not affect Jobs already in flight.
* **Re-activate** is not currently surfaced - to "restart" a schedule, comment on the source ticket and let the gateway re-register.
* **Edit cadence** is also driven from the source ticket; comment on the ticket to change the schedule and the gateway will reinterpret.

## Supported timing and refusals

Schedules can include hour windows, weekday filters, and the Nth weekday of a month. The request must fit one recurring cron expression.

Intervals below 5 minutes in production are refused. The ticket receives an explanation so you can choose a supported timing. The same applies to other timing the platform cannot represent. Scheduling requests are all-or-nothing: if any item is invalid or unsupported, none of the requested schedules are registered. The ticket receives one explanation so you can correct and resubmit the complete request. No part of a rejected scheduling request is installed on the host; unrelated immediate work can still proceed.

## Start, end, and run limits

You can specify when a recurring schedule starts, when it ends, or how many times it runs. For example, "check RAM every 5 minutes for the next 30 minutes" creates a schedule that stops at the requested end.

Relative times use your tenant's timezone unless the request names another timezone. A calendar end date without a time includes that entire date. Invalid or already-expired bounds are refused rather than ignored.

A run count must be a whole number from 1 to 2,147,483,647. Zero, negative, fractional, and larger counts are refused, not rounded or replaced.

## License interaction

Scheduled jobs count against the **same task cap** as ad-hoc jobs. The cap is a lifetime tenant total - see [Licensing](/0.15/configure/licensing).

If the tenant has reached its cap when a tick fires, that tick **skips** rather than queues. The schedule itself stays active; the next tick will try again once headroom exists.