Schedule trigger node

Schedule Trigger Node

Overview

The Schedule Trigger Node automatically initiates MaestroHub pipelines on a recurring cadence. It supports both advanced cron expressions and high-frequency millisecond intervals, giving you the flexibility to automate routine jobs, align pipelines with regional business hours, or capture near real-time telemetry—all without manual intervention.

---

Core Functionality

What It Does

Schedule Trigger keeps your workflows running on time by enabling:

1. Recurring Pipeline Automation
Start pipelines on predictable schedules—from hourly refreshes to monthly closing tasks—without relying on user actions.

2. Cron-Based Precision
Use six-field cron expressions (including seconds) or cron macros (@daily, @hourly, etc.) to model complex timing scenarios.

3. High-Frequency Intervals
Trigger pipelines every 100–900 milliseconds for near real-time monitoring, streaming ingestion, or IoT workloads.

4. Timezone Awareness
Execute cron schedules in any IANA-recognized timezone so that business processes align with local hours and daylight-saving changes.

5. Hands-Free Operations
Keep mission-critical workflows running continuously, even when teams are offline or during maintenance windows.

---

Configuration Options

Parameters Tab

Parameters Configuration

Settings Tab

Settings Configuration

Basic Information

Field	Type	Description
Node Label	String (Required)	Display name for the node on the pipeline canvas
Description	String (Optional)	Explains the intent of the automated workflow

---

Parameters

Parameter	Type	Default	Description
Schedule Type	Enum (cron | interval)	cron	Select cron-based or millisecond interval execution
Cron Expression	String (Required for cron)	0 0 0 * * *	Six-field cron expression (second minute hour day month day-of-week) or cron macro
Interval (ms)	Number (Required for interval)	100	Interval duration in milliseconds (100–900) for high-frequency schedules
Timezone	String (Optional)	UTC	IANA timezone identifier that contextualizes cron evaluation
Enabled	Boolean (Optional)	true	Toggles the schedule on or off without removing configuration
Output Data	JSON Object or null	null	Supplemental payload returned when the trigger fires

---

Settings

Basic Settings

Setting	Options	Default	Recommendation
Retry on Fail	true / false	false	Keep disabled for triggers unless backend resiliency is required
Error Handling	Stop Pipeline / Continue	Stop Pipeline	Use "Stop Pipeline" to prevent cascading failures from recurring triggers

Documentation Settings

Setting	Type	Default	Purpose
Notes	Text	Empty	Capture design intent, SLAs, or release context
Display Note in Pipeline	Boolean	false	Surface notes on the pipeline canvas for faster operator awareness

---

Output Data Structure

Custom Payloads

Schedule Trigger returns exactly what you define in Output Data. Use it to propagate metadata—such as schedule identifiers, timezone context, or downstream routing hints—to the rest of the pipeline. A typical payload might include fields like triggeredBy: schedule, an ISO-8601 timestamp, and a nested metadata object describing the schedule type and expression.

---

Validation Rules

The Schedule Trigger Node enforces strict validation to guarantee reliable execution:

Node Configuration Validation

Label Requirements

• Must not be empty
• Must not contain only whitespace
• Error: "Node name is required"

Schedule Type Validation

• Must be either cron or interval
• Error: "Schedule type must be either 'cron' or 'interval'"

Cron Mode Validation (scheduleType = "cron")

• Cron expression is required
• Cron expression must contain six space-separated fields
• Supports cron macros (@daily, @hourly, etc.)
• Errors include:
  • "Cron expression is required for cron schedule type"
  • "Cron expression must have exactly 6 fields (second minute hour day month day-of-week)"

Interval Mode Validation (scheduleType = "interval")

• intervalMs must be supplied
• Accepted values: 100, 200, 300, 400, 500, 600, 700, 800, 900
• Cron expression is ignored in this mode
• Errors include:
  • "Interval in milliseconds is required for interval schedule type"
  • "Interval must be one of: 100, 200, 300, 400, 500, 600, 700, 800, 900 milliseconds"

Timezone Validation

• Must be a string containing a valid IANA timezone identifier
• Error: "Timezone must be a valid string"

---

Usage Examples

Daily Report Generation (Cron)

Key configuration

• Label: Daily Report Generator
• Description: Runs every day at 09:00 local time
• Parameters: cron schedule (0 0 9 * * *), schedule enabled
• Output data: report type daily, recipients admin@company.com and manager@company.com, format pdf
• Settings: retry disabled, on error stop, pipeline note visible with summary of the workflow

15-Minute Health Monitoring (Cron)

Key configuration

• Label: System Health Monitor
• Description: Checks critical services every 15 minutes
• Parameters: cron schedule (0 */15 * * * *), timezone UTC, schedule enabled
• Output data: health check type, list of target services, alert threshold of 90
• Settings: retry enabled, on error continue, internal note kept off the canvas

High-Frequency Sensor Collection (Interval)

Key configuration

• Label: IoT Sensor Data Collector
• Description: Captures readings every 500 milliseconds
• Parameters: interval schedule at 500 ms, timezone UTC, schedule enabled
• Output data: sensor group temperature-monitors, metrics (temperature, humidity, pressure), storage type time-series-db
• Settings: retry disabled, on error stop, pipeline note shown to operators

Weekly Data Cleanup (Cron)

Key configuration

• Label: Weekly Data Cleanup
• Description: Purges stale data every Sunday at midnight
• Parameters: cron schedule (0 0 0 * * SUN), timezone America/New_York, schedule enabled
• Output data: cleanup type weekly, retention window of 90 days, targets (logs, temp files, cache, old backups)
• Settings: retry enabled, on error stop, documentation note kept internal

Monthly Invoicing (Cron)

Key configuration

• Label: Monthly Invoice Generator
• Description: Processes invoices on the first day of each month
• Parameters: cron schedule (0 0 2 1 * *), timezone Europe/London, schedule enabled
• Output data: invoice type monthly, billing period previous_month, currency GBP, notifications and PDF generation enabled
• Settings: retry enabled, on error stop, pipeline note visible with operational guidance

Temporarily Disabled Schedule (Cron)

Key configuration

• Label: Disabled Weekend Notification
• Description: Weekend notifications (currently paused)
• Parameters: cron schedule (0 0 10 * * SAT,SUN), timezone Asia/Tokyo, schedule disabled
• Output data: notification type weekend-summary, recipient list containing team@company.jp
• Settings: retry disabled, on error stop, pipeline note displayed to highlight the seasonal pause

---

Best Practices

Choosing the Right Schedule Type

Use Cron When

• Jobs rely on specific days, hours, or weekdays
• Timezone alignment and daylight-saving adjustments matter
• You need readable patterns like "every weekday at 09:00"

Use Interval When

• You require high-frequency execution under one second
• Workloads are timezone-agnostic
• Near real-time monitoring or ingestion is required

Avoid

• Long-duration intervals (use cron instead)
• Cron schedules for sub-second timings

Writing Cron Expressions

• Always provide six fields: second minute hour day month day-of-week
• Prefer macros for readable daily or hourly schedules
• Document business meaning for complex expressions
• Remember to add the leading seconds field when converting from traditional five-field cron tools

Reference Table

Field	Range	Special Characters
Second	0-59	*, ,, -, /
Minute	0-59	*, ,, -, /
Hour	0-23	*, ,, -, /
Day of Month	1-31	*, ,, -, /, ?
Month	1-12	*, ,, -, /
Day of Week	0-7 (0 and 7 = Sunday)	*, ,, -, /, ?

Managing Timezones

• Explicitly set the timezone instead of relying on UTC
• Use full IANA identifiers
• Consider daylight-saving transitions when scheduling jobs around local midnight
• For multi-region operations, deploy dedicated nodes per region

Working with Intervals

• Start with higher intervals in testing, then tighten as needed
• Monitor infrastructure load; sub-second triggers can create backpressure
• Avoid 100ms intervals in production without robust throughput handling

Interval Guidance

Interval	Example Use Case	Risk Guidance
100–200 ms	Real-time monitoring	High risk: reserve for short-lived bursts only.
300–500 ms	Frequent data collection	Elevated risk: monitor worker utilization closely.
600–900 ms	Regular heartbeat checks	Moderate risk: safe default for most workloads.

Designing Output Payloads

• Keep payloads concise and structured
• Include metadata such as scheduleType, expression, or timezone
• Document downstream expectations to avoid schema drift
• Avoid bloated payloads that slow downstream processing

Enable vs. Disable

• Use enabled: false for temporary pauses (maintenance, seasonal shutdowns)
• Document the reason in settings.documentation.notes
• Delete the node only when the schedule is no longer needed

Error Handling

• Enable retries for critical cron jobs where transient failures occur
• Combine retries with monitoring to avoid silent failures
• Keep retries disabled for high-frequency interval schedules to prevent overload