Cron Trigger
Run workflows on a recurring schedule.
A cron trigger runs your workflow automatically on a recurring schedule.
Setup
- Add a Cron Trigger node to your canvas
- Click the node to open settings and configure the schedule in the Parameters pane
- Add a Sample Payload if downstream nodes need seeded data for testing
- Click Activate in the editor toolbar, or toggle Active on the workflow's row in the Workflows list
Schedule options
| Schedule | Frequency | Config fields |
|---|---|---|
| Every minute | * * * * * | None |
| Every 5 minutes | */5 * * * * | None |
| Every 10 minutes | */10 * * * * | None |
| Every 15 minutes | */15 * * * * | None |
| Every 30 minutes | */30 * * * * | None |
| Hourly | {minute} * * * * | Minute (0-59) |
| Every 2 hours | {minute} */2 * * * | Minute (0-59) |
| Every 4 hours | {minute} */4 * * * | Minute (0-59) |
| Every 6 hours | {minute} */6 * * * | Minute (0-59) |
| Every 12 hours | {minute} */12 * * * | Minute (0-59) |
| Daily | {minute} {hour} * * * | Hour (0-23), Minute (0-59) |
| Weekly | {minute} {hour} * * {day} | Day of week (0-6), Hour, Minute |
The hour-interval presets fire at hours divisible by the interval (UTC) — every 6 hours means 00:00, 06:00, 12:00, 18:00 at your chosen minute.
The schedule is stored as a standard 5-field cron expression.
Custom cron expressions
When no preset matches — every 20 minutes, weekdays only, the first of the month — pick Custom (cron expression) in the Schedule dropdown and type a standard 5-field cron expression:
┌───────────── minute (0-59)
│ ┌─────────── hour (0-23)
│ │ ┌───────── day of month (1-31)
│ │ │ ┌─────── month (1-12 or JAN-DEC)
│ │ │ │ ┌───── day of week (0-7 or SUN-SAT; 0 and 7 are both Sunday)
* * * * *Each field accepts * (any), exact values, ranges (9-17), steps (*/20, 9-17/2), and comma lists (0,30), and you can mix those within a list. Month and day-of-week also take three-letter names (JAN, MON), case-insensitive. There is no seconds field — the scheduler fires at minute resolution — and everything is evaluated in UTC, same as the presets. Expressions are capped at 120 characters.
Some examples:
| Expression | Fires |
|---|---|
*/20 * * * * | Every 20 minutes |
30 9 * * MON-FRI | Weekdays at 09:30 UTC |
0,30 9-17 * * 1-5 | Every half hour during weekday business hours (UTC) |
0 0 1 * * | First of every month at midnight UTC |
15 8 1,15 * * | The 1st and 15th at 08:15 UTC |
The editor validates the expression as you type and previews the next three fire times (in UTC, plus your local timezone when your device isn't on UTC), so you can confirm the cadence before saving. An invalid expression never activates: the settings dialog blocks saving it, and the workflow validator flags it the same way as a missing schedule.
Two standard cron rules worth knowing:
- Day-of-month and day-of-week follow classic (Vixie) cron: when both are restricted, the expression fires when either matches (
0 0 1 * 1fires on the 1st and on every Monday). When only one is restricted, it gates alone. A day field that starts with*— including steps like*/2— counts as unrestricted for this rule, so0 0 */2 * 1fires only on Mondays that fall on odd-numbered dates, not on every odd date plus every Monday. - Minute steps reset at the top of each hour:
*/7fires at :00, :07, ... :56, then starts again at :00 — the gap across the boundary is 4 minutes, not 7.
Custom expressions follow the same rules as presets everywhere else: each fire is a normal run with the base credit charge, fast schedules suppress success alerts (see below), and the schedule pauses automatically after 4 consecutive failures.
Sample payload
Cron triggers can emit optional JSON seed data. Top-level object fields are available directly, such as {cron.symbol}. If you paste an array or primitive, the editor stores it wrapped as { "body": <value> } and you access it via {cron.body}.
The settings Input pane previews the sample payload while you edit it. If you rerun a cron execution from the editor's executions panel, Solaris AI Flow fires the cron trigger using its current configuration.
Output
Every cron fire emits at minimum:
{
"triggeredAt": "2026-05-14T10:00:00.000Z",
"source": "cron"
}With a Sample Payload such as { "watchlist": ["SOL", "BONK"] }, the trigger output becomes:
{
"watchlist": ["SOL", "BONK"],
"triggeredAt": "2026-05-14T10:00:00.000Z",
"source": "cron"
}Downstream nodes reference fields with the trigger response name (default cron): {cron.watchlist}, {cron.triggeredAt}. The base fields (triggeredAt, source) always win on key collision.
Day-of-week mapping
For weekly schedules, dayOfWeek follows the standard cron convention: 0 = Sunday, 1 = Monday, ..., 6 = Saturday.
Enabling and disabling
Toggle the workflow from:
- The editor toolbar (Activate / Active)
- The Workflows list: the Active control on a cron row, or the row's ••• menu (Activate schedule / Pause schedule)
- The mobile actions menu (Activate Schedule / Deactivate Schedule)
- The
updateScheduleaction on the workflow
When disabled, the cron stops firing but the configuration is preserved.
Activating the schedule is separate from running once. Run on a workflow's row (or in the editor) fires the workflow a single time immediately and leaves the schedule untouched; the Active toggle is what starts and stops recurring firing.
Automatic pausing
If a scheduled workflow fails 4 times in a row, Solaris AI Flow pauses it automatically and shows a deactivation reason on the workflow's row. Any successful run resets the counter, so a one-off failure won't pause the schedule, and a non-critical step set to Continue on failure keeps the run green so the streak never builds. Re-enable the schedule from the Workflows list or editor toolbar once you've fixed the cause. See Error Handling for details.
Notifications and fast schedules
Failure alerts always send, on every cadence. Success alerts are different: a cron that fires more often than every 15 minutes would emit a success notification on every run (an every-5-minute cron is 288 a day), so Solaris AI Flow suppresses success alerts for those schedules.
| Schedule | Failure alerts | Success alerts |
|---|---|---|
| Every minute | Yes | Suppressed |
| Every 5 minutes | Yes | Suppressed |
| Every 10 minutes | Yes | Suppressed |
| Every 15 minutes and slower | Yes | Yes |
The threshold is the gap between fires, so a custom or imported cron expression is measured the same way: 0,50 9-17 * * * has a 10-minute gap at each hour boundary and counts as fast.
In notification settings, each automated workflow has a Success toggle. If a fast cron is the workflow's only automatic trigger, that toggle is off and disabled, with the note "Success alerts are off for high-frequency triggers. Failures still alert." When the workflow also has a slower trigger (a generic Webhook trigger, for example), the toggle stays usable and only the fast cron's runs are dropped, so the webhook runs still alert.
Wallet-activity triggers (Alchemy) are treated as high-frequency for the same reason, independent of any cron on the workflow.
To get a signal out of a fast schedule, put the notification in the workflow itself: add a Telegram or Discord node behind a condition so it only fires on the outcome you care about.
Cost of fast schedules
All cron frequencies are available, including every minute. There is no monthly run cap and no cadence restriction. Each fire is a normal workflow run and uses the base credit charge of 3 credits (plus any loop reservations), so a high-frequency schedule simply uses more credits over time.
Every minute: an every-minute workflow fires about 43,200 times per 30-day cycle, so reserve every-minute schedules for workflows that genuinely need that cadence and keep an eye on your credit balance.
Timezone
Cron schedules run in UTC. Configure the hour/minute relative to UTC.
Next steps
- Executions - what happens when a cron fires
- Credits and Pricing - what a run costs
