Ozone by Docs

Schedules

A schedule runs the project agent on a recurring cadence across the project's repositories, each at its default branch. The instructions can ask it to review code, maintain findings, update knowledge, or do another job on the repository. These are all ordinary runs with the same project-scoped powers.

Organization admins manage schedules. Members can see them, but cannot create, change, delete, or dispatch one.

What you start with#

Every new project comes with one built-in task, Continuous maintenance, already running. It does two jobs in a single pass:

  • Checks open findings against current code and git history, and closes the ones it can prove.
  • Refreshes the knowledge library against the default branch.

It is change-aware rather than nightly. Ozone tracks whether your default branch or your findings have moved since the last successful pass, and runs at most once a day — only the half that has pending changes, and nothing at all when the project is current. Pushes to the default branch are the signal; a daily check against GitHub catches anything a missed webhook lost.

The Schedules page shows it as Changes waiting or Up to date. It is managed, so its time and instructions are not editable and it cannot be deleted — but you can pause it, and Run now forces a full pass even when nothing is pending. A pass that does run is an ordinary run: it takes a slot from your rolling allowance and spends credit.

Creating a schedule#

Schedules are created and edited on the Schedules page. The project page lists a project's schedules and links there. A schedule needs:

  • A cadence — a standard 5-field cron expression, evaluated in UTC. 0 3 * * * is 03:00 UTC nightly; 0 6 * * 1 is Mondays at 06:00 UTC. The minimum interval is once per hour.
  • Instructions (optional) — what the agent should do and what it should leave alone, up to 4,000 characters. "Audit the payment flows for authorization gaps" produces a very different run from "refresh the architecture knowledge from current code." Leave this empty for the standard security review. A skill token anywhere in the instructions applies that skill on every firing — /security-analysis nightly buys the four-hour, $400 budget each night, so choose that cadence deliberately.
  • A name — defaults to <project> analysis.

You can disable a schedule instead of deleting it, and every schedule has a Run now action that starts the analysis at once without shifting its next scheduled time.

Schedules on the same project can run at the same time — starting one does not block another. The only ceiling is your plan's runs-at-once limit, shared across every project and trigger. Continuous maintenance is the exception to itself: it will not start a second pass while its own previous one is still going.

A single schedule still fires once per occurrence. If your plan is at that ceiling when a schedule comes due, its run waits in the queue; if it is still waiting when the next occurrence falls due, the stale one is marked failed with scheduled occurrence expired in the queue rather than run late or run twice. A schedule that fails this way repeatedly is telling you its cadence is tighter than your runs-at-once limit allows.

Costs and limits#

A scheduled run is a normal run: it takes a slot from your plan's runs-at-once ceiling and your rolling 24-hour allowance, and is metered like any other analysis. Reach your spend limit and scheduled runs stop starting until the limit resets or an admin raises it — they will never push you past it.

A good starting setup#

Beyond the two schedules every project starts with:

  • Nightly, focused — 0 4 * * * with instructions naming your riskiest area. Small, cheap, catches drift early.
  • Weekly, broad — 0 6 * * 1 with no instructions, for the agent's full review sweep.

You can also manage schedules by asking the assistant — "run the checkout analysis every weekday at 5am UTC" — or via the API.