Operate schedules

Schedules are defined in config, but you operate them over the API - so pausing a noisy job at 2am does not require a deploy.

After restarting the server with the updated config:

GET  /api/v1/schedules
GET  /api/v1/schedules/{id}
POST /api/v1/schedules/{id}/run
POST /api/v1/schedules/{id}/pause
POST /api/v1/schedules/{id}/resume

Listing and reading are open to any authenticated caller. Running, pausing, and resuming need the platform admin role - these schedules are owned by the system principal, not by you, so dispatching one is acting outside your own data.

axl config init --user-id you@example.com --role admin
TOKEN=$(axl config token)

curl -X POST -H "Authorization: Bearer $TOKEN" "$AXL/api/v1/schedules/<id>/run"

run returns 409 when a forbid schedule already has a run in progress - the policy is working as intended.

When a schedule does not fire

Work through these in order; it is almost always one of them:

1. Timezone - tz is set, and set to what you meant.
2. enabled - it is true.
3. Registration - the named agent or workflow actually exists.
4. last_err - the schedule's own error state, which usually names the problem outright.

Check last_err before anything else if the schedule fired previously and then stopped. A schedule that never fired at all is more likely a timezone or registration problem.

Next

• Create a schedule - the file format and overlap policy.
• Track asynchronous tasks - what a triggered run becomes.
• HTTP API - live request and response schemas.
• Troubleshoot a deployment - when the cause is elsewhere.