Create automations
Run a script on a schedule, or let Sazabi run one when a signal fires — to monitor systems and open issues without being asked.
An automation lets Sazabi do work without being asked. It pairs a trigger with a script: the trigger decides when to run, the script decides what to do. Automations run inside the project sandbox, so they can call the same CLIs and Sazabi tooling the agent uses, including the Sazabi CLI to start an agent investigation. Manage them at the project Automations page.
Outcome: a running automation that monitors something and opens issues when it finds a problem. Time: a few minutes once you have a script.
Trigger kinds
An automation is triggered one of two ways.
- Scheduled — runs a saved script on a cron schedule in a timezone you choose. This is the kind you create for recurring checks and jobs.
- Signal — runs when a specific event occurs in the project (for example, a new log pattern appears). Signal automations include Sazabi-managed behaviors such as Investigate new error patterns, which opens issues for new and spiking error patterns as they appear.
For recurring work you write, create a scheduled automation. Signal automations are event-driven; the highest-value ones ship as Sazabi-managed definitions you enable or disable rather than author from scratch.
What a scheduled automation runs
A scheduled automation runs a saved script. The automation row stores the schedule fields, not the logic — the logic lives in the script:
| Field | Description |
|---|---|
| Name | Shown on the Automations page and in run notifications |
| Script | The saved .sh script to run each time |
| Cron expression | When to run |
| Timezone | The IANA timezone the schedule is evaluated in (defaults to UTC) |
| Timeout | Max runtime in seconds before the run is canceled (1-3600) |
| Enabled | Whether the automation is enabled or disabled |
To have an automation start an agent investigation, write a script that calls the Sazabi CLI, and schedule that script.
The exit-status contract
A run's result is the script's exit code. Exit 0 marks the run succeeded; any non-zero exit marks it failed.
Exit status reports whether the automation executed correctly — not whether the system it inspected is healthy. A monitor that runs, finds a problem, and opens an issue has done its job: it should print what it observed and exit 0. Reserve non-zero for the script itself failing to run, so a failed run always means the automation needs fixing. A script that exceeds its timeout is killed and surfaces as failed.
Creating a scheduled automation
Create one from the project Automations page, or with the CLI against a saved script:
sazabi automations create nightly-health-check \
--script health-check \
--cron-expression "0 9 * * *" \
--timezone "America/New_York" \
--timeout-seconds 120Enable, disable, or run an automation on demand:
sazabi automations enable <automation-id>
sazabi automations disable <automation-id>Runs and health
Every run records its status, exit code, duration, and timing. Run statuses are:
- Succeeded — the script exited
0. - Failed — the script exited non-zero (including timing out).
- Timed out — Sazabi never received a completion and closed the run out after an extended period (an interrupted or orphaned run).
Each automation shows a success rate and a health state derived from recent runs. A failed run can notify you through the Automation run failed notification type (see Route notifications). Inspect run history from the Automations page or the CLI:
sazabi automations runs list <automation-id>Verify
Create a scheduled automation, then run it once immediately using Run now on the Automations page (or trigger the underlying script). Open the automation's run history and confirm a Succeeded run appears with exit code 0 and a recorded duration. If the run shows Failed, open it and check the exit code and captured output — a non-zero exit means the script itself failed to run.