Cron vs Goal Triggers Explained
Who this is for
Users deciding whether to use a cron-based schedule or an AI goal trigger for a recurring infrastructure task.
What you will complete
Understand the difference between cron schedules and AI goal triggers, when to use each, and which is the safer choice for your use case.
The two types of automation in CloudAIPilot
CloudAIPilot offers two distinct ways to automate recurring tasks:
- Site/App cron jobs — traditional time-based tasks that run scripts on your server (configured per site or app)
- AI Pilot goals with triggers — intelligent instructions to the AI that fire on a schedule or in response to an event
This article covers the second type: AI Pilot goal triggers.
Trigger type 1: Schedule (Cron-style)
A schedule trigger fires at a specific time, on a recurring basis. You define when using a cron expression or a human-readable schedule.
Use schedule triggers when:
- You want a task to run at a predictable time regardless of infrastructure state
- The task is routine and time-sensitive (nightly backup at 2 AM, weekly SSL check on Mondays)
- You want consistent, predictable behavior
Examples:
- Create a backup every day at 2 AM UTC
- Check all SSL certificates every Monday at 8 AM UTC and renew any expiring within 14 days
- Restart the application service every Sunday night during the maintenance window
Caveats:
- Scheduled goals still require human approval for write actions. If no admin approves, the goal logs an expiry and tries again next cycle.
- Times are always in UTC. Convert your local time accordingly.
Trigger type 2: Alert Condition (Event-based)
An alert condition trigger fires when a specific monitoring alert fires in your organization. The goal watches for the event and responds.
Use alert condition triggers when:
- You want the AI to react to a problem automatically
- The right response time matters more than schedule predictability
- You want to reduce the time between a problem and a remediation attempt
Examples:
- When a CPU critical alert fires on any server, post an analysis in AI Pilot chat and propose a remediation plan
- When a disk space warning fires, propose running a log cleanup
- When a service goes unreachable, propose restarting it and paging the on-call team via notification channels
Caveats:
- Alert condition goals react to alert firings — they do not resolve the underlying condition themselves without human approval of the proposed action.
- If an alert fires frequently (alert storm), the goal will fire repeatedly. Set appropriate alert hysteresis rules to avoid this. See KB-06-04.
Side-by-side comparison
| Feature | Schedule Trigger | Alert Condition Trigger |
|---|---|---|
| When it fires | At a fixed time (e.g., daily 2 AM UTC) | When a specific alert fires |
| Good for | Routine maintenance, backups, audits | Incident response, self-healing |
| Requires approval | Yes (for write actions) | Yes (for write actions) |
| Fires if target offline | Yes — logs a failure | Only if the alert can still be evaluated |
| Human control | Set and forget (with approval needed) | React as alerts occur |
| Alert storm risk | No | Yes — use hysteresis rules |
Which should you use?
Choose schedule if the task should happen regardless of infrastructure state (backups, SSL renewals, audits).
Choose alert condition if the task should only happen in response to a problem (service restarts, emergency cleanups, incident notifications).
Combine both for critical systems: a schedule trigger for routine maintenance, and an alert condition trigger for emergency response. They do not interfere with each other.