A scheduled deployment allows an agent to start sessions autonomously, enabling task completion over a predictable cadence. You create and manage deployments with the Deployments API, part of the Claude API.
All Managed Agents API requests require the managed-agents-2026-04-01 beta header. The SDK sets the beta header automatically.
When creating a deployment, you pass the session configurations required for execution, in addition to a schedule.
user.message event that starts the session's work.schedule, you define a cron expression and a timezone. Maximum granularity supported is at the minute level.DEPLOYMENT_ID=$(ant beta:deployments create <<YAML | jq -er '.id'
name: Weekly compliance scan
agent: $AGENT_ID
environment_id: $ENVIRONMENT_ID
initial_events:
- type: user.message
content:
- type: text
text: Run the weekly compliance scan.
schedule:
type: cron
expression: "0 20 * * 5"
timezone: America/New_York
YAML
)The response includes a deployment object with a populated schedule.upcoming_runs_at with the next upcoming fire times, to confirm your schedule was set correctly.
{
"id": "depl_01xyz",
"status": "active",
"paused_reason": null,
"schedule": {
"type": "cron",
"expression": "0 20 * * 5",
"timezone": "America/New_York",
"last_run_at": null,
"upcoming_runs_at": [
"2026-05-09T00:00:00Z",
"2026-05-16T00:00:00Z",
"2026-05-23T00:00:00Z"
]
}
}The upcoming run timestamps are based on the exact schedule configured. However, to distribute load, deployments may apply jitter of up to 10 seconds.
A maximum of 1,000 scheduled deployments is supported per organization. Contact Anthropic support if you need more.
See the Create Deployment reference for full parameters and response schema.
minute hour day-of-month month day-of-week). You can generate and validate these cron expressions in the Claude Console."America/Los_Angeles")."0 20 * * *" in America/New_York fires at 8 PM local time regardless of whether EST or EDT is in effect.Wall-clock times that do not exist on a spring-forward day (such as 2 AM) are not triggered. Wall-clock times that occur twice on a fall-back day fire twice. Schedule outside the 1–3 AM local window, or use UTC, when missed or duplicate executions are unacceptable.
Deployments can fail to trigger for a variety of reasons: for example, if the environment resource has been archived, or if session creation is rate-limited. Each attempt at executing a deployment generates a deployment run record, allowing you to track successes and failures independent of the session lifecycle.
Successful deployments generate active sessions, and a successful deployment run contains the associated session_id. To follow a session's lifecycle, track the session events through the event stream or webhooks. Deployment lifecycle changes and the outcome of each scheduled run are also delivered as webhook events, listed in the Deployment events and Deployment run events tabs of Supported event types.
List all deployment runs for a deployment as follows:
ant beta:deployment-runs list --deployment-id "$DEPLOYMENT_ID"You can additionally filter on deployment runs with errors:
ant beta:deployment-runs list --deployment-id "$DEPLOYMENT_ID" --has-errorA failed run includes an error with a type describing why session creation was rejected (for example, environment_archived_error, agent_archived_error, or session_rate_limited_error). See the List Deployment Runs reference for all filter parameters and the response schema.
{
"type": "deployment_run",
"id": "drun_01abc124",
"deployment_id": "depl_01xyz",
"trigger_context": { "type": "schedule", "scheduled_at": "2026-05-09T00:00:00Z" },
"session_id": null,
"error": {
"type": "environment_archived_error",
"message": "environment `env_01abc` is archived"
},
"agent": { "type": "agent", "id": "agent_01ghi789", "version": 3 },
"created_at": "2026-05-09T00:00:01Z"
}To retrieve a single run by ID, call GET /v1/deployment_runs/{deployment_run_id}. A deployment_run webhook event carries the run ID as its data.id.
Each lifecycle change emits a webhook event, so you can react to a paused, unpaused, or archived deployment without polling; see the Deployment events tab.
Pause suppresses scheduled triggers on a go-forward basis; running sessions from a prior deployment run continue to execute. Manual runs through the run endpoint are still allowed while paused. Pausing sets paused_reason to {"type": "manual"}; unpausing clears it.
ant beta:deployments pause --deployment-id "$DEPLOYMENT_ID"Unpause resumes the schedule from the next scheduled occurrence. Missed triggers are not backfilled.
ant beta:deployments unpause --deployment-id "$DEPLOYMENT_ID"Archive, unlike pause, is terminal: the schedule terminates and the deployment cannot be modified.
ant beta:deployments archive --deployment-id "$DEPLOYMENT_ID"Session creation rate-limit responses are recorded immediately as a session_rate_limited_error run without retry; the schedule attempts again at the next scheduled occurrence. Rate limits on underlying API calls within a session are handled by the session itself.
If a deployment's agent has been archived or deleted, the deployment is automatically archived in the same operation; no deployment run is recorded. If a subagent referenced by the agent has been archived, the next trigger records a failed run with error.type: "agent_archived_error" and the deployment is automatically paused so you can update the agent and resume. Other unrecoverable session-creation errors, such as an archived environment or vault, behave the same way: the trigger records a failed run and the deployment is automatically paused. The deployment's paused_reason.error.type mirrors the failed run's error.type.
To run a deployment outside its schedule, call the run endpoint. This creates a session immediately and writes a deployment run with trigger_context.type: "manual". This allows you to test a deployment before committing to the schedule.
ant beta:deployments run --deployment-id "$DEPLOYMENT_ID"Was this page helpful?