Jern Cloud docs

Run a session on a schedule.

A schedule belongs to a repository: a five-field cron, a time zone, the message each run starts with, and an optional cap per run. Every run opens a session as the member who set the schedule and ends in a pull request like any other.

Adding a schedule

On the repository's page under Repositories, anyone who can start sessions on the repository can add, change, pause, and delete its schedules. A schedule is:

Field	Meaning
When	A preset such as every Monday at 09:00, or a custom cron: minute, hour, day of month, month, day of week.
Time zone	An IANA zone such as `Europe/Madrid`, chosen from a list. Runs follow the zone through clock changes.
What each run should do	The message every run starts with, up to 16,000 characters. "Update the dependencies and open a pull request" is the first use.
Token cap per run	Optional. It can lower the cap per triggered session for these runs, never raise it.
On	A paused schedule keeps its settings and runs nothing.

The list shows each schedule's next run and what became of the last one: the session it opened, or why it was refused. A repository carries at most twenty schedules.

How a run happens

A schedule is one more trigger. The scheduler looks every thirty seconds; a due schedule is claimed once and moved to its next time in the same transaction, so a run happens once even with two API instances. The run opens a new session as the member who set the schedule, with the workspace's trigger model, under the same approval requirement, concurrency limit, allowance, and provider keys as a label or comment. The first message is the schedule's message followed by a line naming the schedule and the time it was due, so the agent can say so in the pull request.

Runs are at least an hour apart; a cron closer than that is refused when written, as is one that never comes due in the coming year. A schedule that was due while Jern Cloud was unavailable runs once when it comes back, not once per missed time.

What can stop a run

Triggers must be on under Settings › Triggers; a schedule under a workspace whose triggers are off is refused at its time. A schedule keeps acting as its creator: if that member loses write access or leaves the workspace, the run is refused. Any refusal is a workspace notification, an audit event, and the schedule's last outcome, shown in the list. If a stored cron or zone can no longer be read, the schedule is paused with that outcome rather than fired.

Campaigns

A schedule opens a session on the clock and has no opinion about what comes back. A campaign is a schedule with terms, so unattended maintenance, starting with dependency upgrades, is safe to turn on and leave on. Add one from the repository's Automation section. Its terms:

Total budget: the whole purse in dollars; when it is spent, the campaign stops. A cap per run bounds each run's tokens.
Open pull requests: how many of its pull requests may wait for review at once, across every repository it runs on.
Accept paths: the only paths a run may change, so an upgrade does not turn into a refactor.
Criteria: named one-line commands, such as build: gradle --offline build, that run after the agent finishes and are listed on the receipt with their verdicts.
Failure limit: how many unaccepted runs in a row stop the campaign until someone edits it.
Roll out to: the other repositories it widens to.

A run is accepted when it published a pull request, the acceptance run found no failures the tree did not already have, every criterion passed, and every changed path is inside the accept paths. The repository a campaign is written on is its canary: the campaign runs only there until it has the accepted runs it asks for, and then widens to the rest. A run that would start from the same tree as an earlier one is skipped, so the same upgrade is not proposed twice.

Seeing what it costs

Unattended work has a bill. The usage report shows spend by repository for any month, with the part that schedules started beside the whole, and downloads as a CSV.

A first schedule. Every Monday at 09:00 in your zone, "Update the dependencies to their latest compatible versions, run the tests, and open a pull request that lists what changed." With a skill describing how your changelog is written, the pull request arrives with its entry.