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 on @rrulenet/recurrence, with a hosted platform, API, CLI, MCP server, and libraries sharing the same recurrence model.

See the ArchitectureTry the APIView Pricing

From schedule to webhook

Describe your schedule using natural language, cron or RRule syntax
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.

Cron

Field-based

What cron actually does

*/25 * * * *
  • 16:25
  • 16:50
  • 17:00
  • 17:25
  • 17:50

Cron matches allowed minute values inside each hour. It resets at the hour boundary instead of preserving a true elapsed interval.

Rule-first

Interval-aware

What RRule does is what many people expect

Every 25 minutes
  • 16:25
  • 16:50
  • 17:15
  • 17:40
  • 18:05

RRule models an actual 25-minute interval, so the sequence keeps the elapsed timing people usually mean.

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 on the @rrulenet recurrence stack

A shared set of libraries for parsing, explaining, composing, and executing recurring schedules.

The hosted platform now relies on @rrulenet/recurrence as the canonical schedule model. It supports composed schedules, legacy RRule compatibility, explanations, timezone-aware previews, and the same semantics across API, dashboard, CLI, and MCP.

Temporal-based time model

Built on Temporal semantics for serious timezone and DST-aware recurrence computation.

Composable by design

Schedules can be simple rules, unions, intersections, or differences without forcing everything into one flat RRule.

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 PricingGet API Access

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