Skip to main content
Schedules connect a five-field cron expression and an IANA timezone to one execution target. They are durable control-plane definitions: operators can pause, run, edit, delete, restore, and audit them independently of any one execution.

​
Operate configured Schedules

Open Jobs → Schedules to see the current schedule estate. The grid exposes name, category, description, active state, a human-readable Execute value derived from cron, timezone, target type, target ID, metadata, ownership, version, and deletion state. Use grid filters to answer operational questions before opening a definition:
  • which production schedules are inactive;
  • which definitions target a retiring Job template or Agent;
  • which workload owns a timezone-sensitive cadence;
  • which schedules were changed or deleted during an incident;
  • which rows are RevoEngine-managed internal schedules.
Selecting a row opens its effective configuration. RevoEngine-managed schedules are labelled INTERNAL, hide customer target details, and are read-only; their owning platform resource controls them.

​
Choose a schedule target

Use an Event instead when the trigger is a business or platform state change. Use an Endpoint when a caller needs a synchronous response.

​
Configure in the UI

Open Jobs → Schedule, select Add, then provide: The editor displays a human-readable cron description after validation.
This fires at 09:30 on weekdays in Warsaw time and follows daylight-saving changes. Abbreviations such as CET and EST are rejected because they do not provide stable DST rules.

​
Cron field reference

The expression describes cadence; the timezone decides how wall-clock times map to real instants. For DST-sensitive business jobs, test the spring and autumn transitions and decide whether a skipped or repeated local hour is acceptable.

​
Configure Runtime input for a Job target

For a Job target, use the expanded Options section at the bottom of the Schedule editor. Enter a JSON object in Runtime input, using the same editor as Job templates, and select Override, Deep Override or Replace from the dropdown with icons and descriptions. Override is shallow: nested objects and arrays replace the value at their top-level key rather than merging recursively. Values such as false, 0, and null inside the object are retained. The root must be an object; arrays, strings, numbers, and null are rejected. Use Deep Override to change part of a nested configuration. For example, Job defaults { "export": { "format": "csv", "encoding": "utf8" } } and automation input { "export": { "format": "xlsx" } } produce { "export": { "format": "xlsx", "encoding": "utf8" } }. An empty nested object preserves existing nested values; a change of value type replaces the whole value. Arrays are never concatenated, and null does not delete a field. Existing Override and Replace behavior is unchanged. The Component reads the resolved object through api.input('templateInputs'). These settings apply to both cron occurrences and manual Run. They do not change the Job template’s execution policy, concurrency, or retry settings, and do not configure Agent or Materialized View targets. The Platform API uses inputMode: "override" for Override, inputMode: "deep_override" for Deep Override and inputMode: "replace" for Replace, matching the UI. Existing definitions are migrated without changing their effective behavior. New definitions use input: {} and inputMode: "override" by default, preserving Job defaults. API updates retain stored fields when those fields are omitted. Send both fields to return to the defaults.

​
One export Job, two cadences

Keep one price-list export Job template with Runtime input:
Create two Schedules targeting that same template: Both keep region: "eu" and share the template’s Component, principal, concurrency, and retry policy. The Component selects the export path from api.input('templateInputs').full. An accepted occurrence retains its Runtime input and mode. Later Schedule edits affect subsequent occurrences, not Jobs already queued or running or their retry attempts.

​
Public configuration shape

The Platform API stores the same effective model shown in the UI:
Updates include the current version. If another operator saved first, the stale update is rejected and the editor must reload before retrying. Instance settings govern total and active customer Schedule quotas. RevoEngine-managed system schedules are excluded from those customer counters.

​
Agent schedule modes

Agent targets expose two distinct modes:
  • Run task creates concrete recurring work with an instruction and trigger lineage. Choose INBOX for durable queued delivery or DIRECT_RUN for an immediate run.
  • Wake inbox asks the Agent to claim work already queued. If the inbox is empty, the tick is a no-op; it does not invent a fallback run.
Write an Agent instruction as an executable outcome, including scope and completion evidence. Do not put secrets in the instruction. The public Agent target configuration is explicit:
WAKE_INBOX stores only the wake mode; it does not use a delivery mode or instruction. Agent schedules always execute the current Agent definition rather than pinning an older Agent version.

​
Materialized View refresh schedules

Selecting Materialized view in the UI persists a governed platform-operation target:
Create and manage this schedule from the Materialized View workflow or the Schedule editor. Other platform-operation kinds are system-owned and cannot be created as arbitrary customer schedules.

​
Run now, pause, and resume

  • Run triggers the current target immediately without changing its future cadence.
  • Disable pauses future scheduled delivery.
  • Activate resumes it.
  • Delete is recoverable and removes the definition from normal operation.
  • Restore returns a deleted definition for review.
AUTOMATION_RUNNER or AUTOMATION_ADMIN can run a schedule. Configuration and lifecycle changes require AUTOMATION_ADMIN; reading requires AUTOMATION_READ or AUTOMATION_ADMIN. Manual Run requires an active schedule and asks the scheduler to execute it now; it does not create a second cadence or move the next cron occurrence. An inactive schedule returns a non-success result until it is activated. Customer configuration actions are rate-limited to 10 scheduler operations per instance per 60 seconds. Bulk deletion accepts at most 10 Schedules at once. A 429 response includes a retry interval; wait for that interval instead of immediately retrying every selected row.
RevoEngine-managed schedules are visible for operational transparency but are read-only. They cannot be edited, run, disabled, restored, or deleted manually.

​
Delivery semantics

A successful schedule tick means the target was admitted for dispatch, not that its business work finished. Inspect Job history, Agent runs, or the materialized-view state for the outcome. Scheduling infrastructure may retry delivery. Use target-level idempotency for consequential side effects and design recurring work so a delayed tick can be distinguished from a duplicate. The scheduler delivers a Schedule identity and occurrence time. On first acceptance, the platform reads the current definition and stores the accepted target. Retries of that same occurrence use its accepted snapshot; editing the Schedule affects subsequent occurrences, not work already accepted.

​
Schedule History

Open Jobs → Schedule History to inspect accepted occurrences across the instance, or open one Schedule’s details for the filtered view. Each accepted cron tick or manual Run has one occurrence record. Schedule History ID identifies that occurrence; Schedule ID identifies the definition that produced it, and the adjacent Schedule reference resolves its name and opens the scheduler. The grid uses date filters for scheduled and audit timestamps, UUID filters for identifiers, a numeric Version filter, and the standard show/hide-deleted control. For a Job target, select the Job reference in details to inspect execution and retry evidence. Manual Run first stores and publishes an ACCEPTED occurrence and only then submits dispatch. The returned scheduleHistoryId therefore identifies a row that already exists. If queue submission fails, the same row becomes ERROR with TRANSPORT_SUBMISSION_FAILED; it is not hidden behind an internal task. Repeated delivery of a completed occurrence does not create another history row. Disabling a Schedule prevents future ticks; it does not create synthetic skipped rows for every time the Schedule would otherwise have run. History begins when occurrence recording is enabled, without fabricated historical executions. Every accepted occurrence freezes the target. Job-template and platform-operation execution identities are deterministic for that occurrence, so transport replay returns the original execution instead of starting a second one. Direct Agent runs use the same occurrence identity; queued Agent delivery keeps the occurrence dedupe key on its durable Inbox item. For API access, use GET /api/v1/automation/schedule-history with a scheduleId filter, or GET /api/v1/automation/schedule-history/{scheduleHistoryId} for one occurrence. Job records expose scheduleHistoryId, including retry children.

​
Real production patterns

​
Business-day settlement

Run a Job template at 15 18 * * MON-FRI in Europe/Warsaw. The Component reads unsettled rows using a transaction, writes a settlement batch, and sends the batch ID to an external provider with an idempotency key.

​
Hourly integration reconciliation

Run at 0 * * * * in UTC. Store the source cursor in a Table, not in the Schedule metadata, and make each page checkpoint durable before advancing.

​
Reporting view refresh

Target the materialized view directly. Dashboard widgets read the refreshed view while the schedule remains independently pausable during maintenance.

​
File-ingestion safety sweep

Use an Event for the normal STORAGE_CREATED path, then run a Schedule every hour to query durable Storage entries that have no completed processing record. The sweep repairs missed post-commit event delivery without turning the clock into the primary ingestion trigger.

​
Failure and recovery

Confirm the target still exists and remains enabled, then inspect scheduler admission and service-account authorization. The schedule grid proves configuration, not target completion.
Compare scheduled-delivery evidence with the manual invocation, including admission status and execution-principal authorization. Do not assume the Job or Agent target is faulty merely because manual invocation uses a different admission path.
The active definition no longer has a valid managed scheduling identity. Pause/delete and recreate it through the supported lifecycle instead of editing internal identifiers directly.
Treat scheduler delivery as at-least-once. Use the schedule ID plus intended business period as a durable idempotency key and reconcile provider state before retrying.
Disable or retire unused customer Schedules, or have the instance administrator review the configured total and active quotas. System-managed schedules are separate and cannot be removed to free customer capacity.

​
Production checklist

  • Use an IANA timezone and test DST boundaries.
  • Document the schedule owner and recovery procedure.
  • Configure the target principal with least privilege.
  • Make duplicate and late delivery safe.
  • Monitor target terminal state, not only schedule admission.
  • Pause before changing a consequential target.
  • Keep system-managed schedules read-only.
  • Review inactive, deleted, and orphaned target definitions as part of automation hygiene.
See Jobs for execution policy, Events for state-driven automation, Materialized Views for refresh evidence, and the generated Platform API reference for every current Automation Schedule operation.
Last modified on October 14, 2026