Routines

A recurring responsibility with instructions, a trigger, a model, skills, connectors, results, and limits.

A routine is the unit of work. Everything else — runs, traces, webhooks — exists because a routine ran.

Instructions should describe the outcome, evidence expectations, boundaries, and escalation behaviour that remain stable from run to run. Use variables for values such as a repository, a reporting window, or a campaign.

Writing instructions covers this in depth — it is the highest-leverage page in the knowledge base.

Schedule

Schedules use five-field cron expressions and an IANA timezone. The scheduler calculates the next occurrence in that timezone, including daylight-saving transitions.

0 9 * * 1

This example runs at 09:00 every Monday in the routine's timezone. A cron expression that can never produce a future occurrence is rejected with 400 invalid_schedule.

Limits

Every routine bounds its runs in time, never by a step count. The idle timeout (idleTimeoutSeconds, 60–1800, default 600) stops a run that records no progress event — no model turn, tool call, tool result, or phase marker — for that long. The absolute deadline (timeoutSeconds, 30–3600, default 1200) is the wall clock a run never outlives. Either bound ends the run as timed_out, classified idle_timeout or timeout respectively.

Limits are a cost and blast-radius control, not a performance setting. A run that keeps making productive progress is never stopped mid-work by an arbitrary step budget; a stalled run is stopped quickly. Usage and billing guardrails — run starts, concurrency, and included AI usage — still apply independently of these timers.

Tools

Tools reach a routine through a connection, and are governed by a per-routine tool policy. A tool policy always references a saved connection — creating a routine with inline tool definitions returns 400 tool_policy_requires_connection.

Lifecycle

Status	Meaning
`draft`	Editable, and available for manual proof runs.
`active`	Eligible for scheduled execution.
`paused`	Retained with history, but not scheduled.
`archived`	Hidden from normal lists. Cannot run.

Activation requires a successful manual run of the current configuration. Changing instructions, model, variables, schedule, limits, webhook delivery, discovered tools, or tool permissions returns the routine to draft and requires a new manual proof. Pausing does not delete history or invalidate an otherwise current proof.

Archiving is how deletion works: DELETE /v1/routines/:routineId sets the status to archived and keeps the run history intact.

Webhooks

Adding a webhook URL returns a signing secret once in the same response. Only the encrypted form is stored, so rotating means setting the URL again. See Receive run webhooks.

Results and delivery status

The routine editor keeps Connectors separate from Results. Connectors may expose approved tools to the model. Results are outbound-only destinations that receive run.succeeded, run.failed, or both after a terminal run.

Run status and delivery status are independent. A successful run remains successful if Discord is rate limited, revoked, or exhausts delivery retries; the destination attempt is shown separately as pending, delivered, or failed. Likewise, a failed run may still deliver its bounded failure summary. Delivery never includes raw provider responses, model traces, credentials, or internal stack details.