Recurring time needs a new foundation

Cron was good enough for a narrower era. Modern systems need recurring schedules that are explicit, explainable, timezone-safe, and simulation-first.

Built today on rrule-temporal and Temporal, with a hosted platform, API, CLI, and MCP server built on the same recurrence model.

See the Architecture Try the API View Pricing

From schedule to webhook

The Problem

Cron can trigger jobs. It cannot model recurring time seriously.

Recurring time has richer meaning than cron can represent safely.

Execution syntax, not time semantics
Cron tells a machine when to fire. It does not describe the calendar meaning clearly enough.
Weak timezone and DST story
As soon as wall-clock meaning matters, DST and timezone handling become a source of drift and confusion.
Poor fit for simulation and explanation
Modern systems need to answer not only when, but why this date and what happens next.

Cron

0 9 1 * 1-5

Compact, but unclear: does it mean the first business day, the first weekday run, or something else?

Rule-first

Every first business day at 09:00 Europe/Paris

The calendar intent is visible in the rule itself, so it can be reviewed, simulated, and explained.

A Better Foundation

What a modern recurrence architecture should provide

A recurrence rule should be readable, simulable, explainable, and safe to execute.

Explicit rules
Describe calendar intent, not just firing conditions.
Timezone and DST correctness
Preserve wall-clock meaning across real timezones and seasonal clock changes.
Explainability and simulation first
Preview rules and understand their future dates before production execution.

Foundation

Built today on rrule-temporal

A Temporal-based recurrence engine used here to make recurring time safer, more explicit, and easier to trust.

rrule-temporal

The ecosystem currently relies on rrule-temporal to close correctness gaps in legacy recurrence tooling and make occurrence computation safer across DST transitions, real timezones, and long-running schedules.

Temporal-based time model

A stronger base than legacy JavaScript date handling for serious recurrence computation.

Future-proof by principle

The commitment is to correctness, explicability, and reliability. The implementation can evolve over time.

The Platform

Why a hosted platform matters

A better model is useful only if teams can put it into production without operating recurrence infrastructure themselves.

Hosted schedule execution
Run recurring workflows without building and maintaining your own scheduler stack.
API and dashboard access
Use the platform interactively or integrate it directly into your systems.
Managed persistence and delivery
Keep recurrence rules, webhook targets, execution state, and history in one place.
Explainable operations
Understand not only when something runs, but why, before and after production execution.

rrule.net is the fastest way to put this architecture into production. Use the dashboard when you want interactivity, the API when you want integration, and a subscription when you want managed execution.

Subscriptions

Use the architecture as a service

Subscribe to use a stronger recurrence model without operating the infrastructure yourself.

For builders
API access and managed schedules without maintaining your own recurrence backend.
For operators
Hosted execution and less time spent debugging the semantics of time.
For teams
Shared recurrence semantics across dashboard, API, CLI, and AI-assisted workflows.

View Pricing Get API Access

Start with the API. Move into managed scheduling. Scale with plans that match real usage.