Schedules

The On Schedule trigger runs your pattern at regular intervals based on a cron expression. This is the right trigger for any automation that needs to happen on a predictable cadence — polling an API, generating daily reports, syncing data between systems, or running periodic cleanup.

How scheduled triggers work

When you deploy a pattern with an On Schedule trigger, the execution engine registers the cron expression and begins firing executions at the specified times. Each tick of the schedule creates an independent execution of the pattern.

The schedule is only active while the pattern is deployed. If you undeploy the pattern, the schedule stops. When you redeploy, the schedule resumes from the next matching time.

Cron expression format

DRAGOPS uses standard five-field cron expressions:

┌───────────── 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, where 0 and 7 are Sunday)
│ │ │ │ │
* * * * *

Each field accepts:

Common schedule patterns

Here are cron expressions for the most common automation schedules:

High frequency

Daily

Weekly and monthly

Setting a schedule

1. Add an On Schedule node to your pattern (or replace the existing trigger).
2. Select the On Schedule node.
3. In the Inspector Panel, enter your cron expression in the schedule field.
4. Deploy the pattern to activate the schedule.

The execution engine validates your cron expression at deploy time. If the expression is invalid, the deployment fails with a descriptive error.

Catch-up behavior

If the execution engine restarts — for maintenance, scaling, or recovery — some scheduled ticks may be missed during the downtime window. DRAGOPS handles this automatically:

Missed ticks within the last hour fire automatically when the engine comes back online.

This means a pattern scheduled for every 15 minutes that misses two ticks during a 30-minute restart window fires both missed executions immediately after recovery. Ticks missed more than one hour ago are not recovered.

Catch-up ensures your periodic automations stay consistent without manual intervention after brief maintenance windows.

What catch-up does not cover

• Downtime longer than one hour. If the engine is offline for more than an hour, only the ticks from the most recent hour fire on recovery. Earlier ticks are skipped.
• Overlapping catch-up runs. Each catch-up execution runs independently. If your pattern is not designed for concurrent runs, consider adding idempotency checks.

Timezone considerations

Cron expressions in DRAGOPS run in UTC. When you schedule a pattern for 0 9 * * *, it fires at 9:00 AM UTC.

To convert from your local time:

• US Eastern (EST/EDT): UTC is 5 hours ahead of EST, 4 hours ahead of EDT
• US Pacific (PST/PDT): UTC is 8 hours ahead of PST, 7 hours ahead of PDT
• Central Europe (CET/CEST): UTC is 1 hour behind CET, 2 hours behind CEST

Example: To run a pattern at 9 AM US Eastern (EST), set the cron expression to 0 14 * * * (9 AM + 5 hours = 2 PM UTC).

Keep daylight saving time in mind. Schedules that must align with local business hours may shift by one hour twice a year.

Testing scheduled patterns

Because On Schedule fires on a timer, you cannot wait for the trigger during development. Instead, test your pattern by providing sample event data manually:

1. Select Run in the toolbar.
2. Leave the event data empty (On Schedule has no input data) or provide test values if your pattern uses variables.
3. Select Run to execute the pattern.

This runs the full pattern logic without waiting for the cron schedule to fire.

Best practices

• Keep scheduled patterns fast. Long-running patterns that overlap with the next tick create queueing issues. If processing takes longer than the schedule interval, increase the interval or break the work into smaller batches.
• Handle failures gracefully. A scheduled pattern that fails silently every five minutes generates noise. Add error handling with Try/Catch nodes and use HTTP Request nodes to send failure alerts to your team's notification channel.
• Avoid overlapping runs. If your schedule fires every minute and your pattern takes two minutes to complete, executions overlap. Design for this by either increasing the interval or making your logic idempotent so overlapping runs do not cause data corruption.
• Start with longer intervals. Begin with a conservative schedule like */15 * * * * and tighten it once you understand the pattern's performance characteristics and resource usage.
• Monitor execution history. Check the executions page regularly for failed runs. A scheduled pattern that fails repeatedly may need attention even though it restarts automatically on the next tick.
• Use descriptive pattern names. Scheduled patterns run in the background with no human trigger. A clear name like "Daily Slack standup reminder" or "Hourly EC2 health check" helps you identify what each schedule does at a glance.

Related

• Triggers overview -- comparison of all trigger types
• Webhooks -- event-driven triggers from HTTP requests
• Pattern calls -- invoke patterns from other patterns
• Deployments -- deploying patterns to activate triggers
• Executions -- viewing run history and logs