Run work without a person present

What a schedule does and does not say

A schedule says when you intend work to start. It is a statement about your business, not about what Compute can serve at that moment.

Availability is decided separately, at admission, every single time. So an occurrence can be due and still be refused, and that refusal names its own reason and next action.

Keep the two ideas apart when you design an automation. Ask for the time you actually need, and plan for an occurrence that does not run.

What every occurrence needs

Automation removes the person, not the checks. Each occurrence carries three things of its own.

• A bounded identity. Automation runs on its own scoped key, never a person's session.
• Current policy. Spend ceilings, approvals and profile values are read fresh at the occurrence, never remembered from setup.
• A fresh quote. Prices and limits are re-established for that run, so a stale estimate cannot admit work.

You approve the bound once, at activation. You do not approve each occurrence individually, which is exactly why the bound has to be one you would accept unattended.

Pages in this group

• Create a schedule — time zone, daylight saving, overlap, misfire, catch-up and a maximum-runs bound.
• Start work from an event — provenance, a frozen snapshot and one occurrence identity.
• Occurrences and replay — what stays the same on a replay, and what makes new work.
• Trigger from your own scheduler — external orchestrators as clients, not authorities.
• Receive webhooks safely — verify on raw bytes, then fetch canonical state.
• Pause, revoke and recover — stopping new work without breaking work in flight.