Create a schedule

A schedule is a single file. Create axl-config/schedules/ops/daily-digest.md:

+++
name = "Daily Ops Digest"
schedule = "0 9 * * 1-5"
tz = "America/Chicago"
agent = "assistant"
enabled = true
concurrency = "forbid"
+++

Summarize overnight alerts and produce a concise morning digest.

The path becomes the ID - this one is ops/daily-digest - so directory structure is naming. And the Markdown body is the prompt, which means writing a schedule is mostly writing a good instruction.

Set tz explicitly. A schedule without a timezone shifts during a daylight-saving change.

Agent-created jobs (scheduled_jobs, from the cron tool set) reject a past datetime outright, with an error naming the current server time.

Running a workflow instead

Set workflow and optional workflow_input in the frontmatter, and leave the body empty. The workflow must already be registered under the system principal axl:system.

If it is not, the server warns at boot and then every fire fails and backs off. That shows up on the schedule as a climbing err_count and a last_err naming the missing workflow, so check those first when a handler-mode schedule appears to do nothing.

Overlap policy

concurrency = "forbid"

Use forbid unless overlapping runs are genuinely intentional. If a job usually takes two minutes and one morning takes twelve, permitting overlap means the next run starts on top of it - and for anything that writes, two copies racing is worse than one running late.

What the setting actually controls

The answer differs by mode.

A task-mode schedule never overlaps itself, whatever concurrency says. The prompt runs inline to completion before the schedule re-arms, so a run that overruns its next trigger simply skips the intervening ticks and fires next at the first occurrence after it finishes. Setting concurrency = "allow" drops the overlap guard; it does not make prompt runs concurrent.

The setting matters in handler mode. Submitting a workflow returns immediately, so without forbid the next tick submits a second run on top of the first. Under forbid the schedule checks whether the previous run is still active and skips the fire if it is - and a liveness check that errors counts as active, so a transient Redis failure defers the fire rather than admitting a duplicate.

Next

• Operate schedules - inspect, pause, resume, and trigger manually.
• Build workflows - for the workflow mode above.
• Schedule reference - every frontmatter field.