Job Schedules

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 that follows the normal lifecycle. Schedules are managed under Job Schedules in Command Center.

​

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, which plans and creates the 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

​

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. 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.