Schedules and triggers

QuickFlow schedules manage recurring sync requests. Pipeline schedules and triggers are operational declarations attached to a pipeline source revision and create executions against the deployed published version.

QuickFlow schedules

GET  /vegaflow/quickflows/{quickflow_id}/schedules
POST /vegaflow/quickflows/{quickflow_id}/schedules
GET  /vegaflow/quickflows/{quickflow_id}/schedules/{schedule_id}
PUT  /vegaflow/quickflows/{quickflow_id}/schedules/{schedule_id}
DELETE /vegaflow/quickflows/{quickflow_id}/schedules/{schedule_id}

Store an IANA time zone with every cron expression. The schedule record exposes whether it is enabled and its next eligible run time. Updating a QuickFlow with an inline schedule: null removes its inline schedules.

Run the QuickFlow manually before adding recurrence. Schedule operations affect future launches:

If a scheduled run is missing, confirm that the QuickFlow and schedule still exist, the schedule is active and the next run time is correct. Then check credentials, secret access, cluster readiness, selection and cursor settings, and the execution identity's permissions.

Pipeline schedules

GET  /pipelines/{pipeline_id}/schedules
POST /pipelines/{pipeline_id}/schedules
GET  /pipelines/{pipeline_id}/schedules/{schedule_id}
PUT  /pipelines/{pipeline_id}/schedules/{schedule_id}
DELETE /pipelines/{pipeline_id}/schedules/{schedule_id}
PUT  /pipelines/{pipeline_id}/schedules/{schedule_id}/state
POST /pipelines/{pipeline_id}/schedules/{schedule_id}/executions

Deleting a schedule retires the declaration rather than erasing executions it created. The state endpoint enables or disables an active declaration without changing its historical definition.

Use the execution endpoint for an authorized manual start attributed to that schedule. It follows the same deployment and concurrency checks as a timed firing.

Event triggers

GET  /pipelines/{pipeline_id}/triggers
POST /pipelines/{pipeline_id}/triggers
GET  /pipelines/{pipeline_id}/triggers/{trigger_id}
PUT  /pipelines/{pipeline_id}/triggers/{trigger_id}
DELETE /pipelines/{pipeline_id}/triggers/{trigger_id}
PUT  /pipelines/{pipeline_id}/triggers/{trigger_id}/state

Triggers define an accepted event source, matching/configuration rules and operational state. An incoming event is first persisted as a trigger event, then matched and delivered to an execution.

POST /pipeline-projects/{project_id}/events
GET  /pipeline-projects/{project_id}/events/{event_id}

Delivery identity

Producers should send a stable source event ID. Repeated delivery with the same source identity is idempotent; it must not create an arbitrary number of executions. The event resource shows whether delivery was accepted, ignored or queued.

Concurrency and missed runs

An enabled declaration does not guarantee that every theoretical time produces overlapping work. Environment readiness, active-run policy, queue limits and project state can delay or reject a firing. Use the event/schedule execution record to distinguish:

• scheduler did not become due;
• due occurrence was deduplicated;
• execution was queued;
• queue/admission rejected the work;
• execution started and later failed.

Safe schedule changes

1. Disable the existing declaration when changing cadence or event semantics materially.
2. Wait for active executions according to your workload policy.
3. Update or create the declaration against the intended source revision.
4. Validate the next run time or a sample event.
5. Re-enable and observe the first delivery.

Always keep schedule time zone and event identity explicit. Defaults become production ambiguity during daylight-saving changes and delivery retries.