메뉴
Durable cron jobs with Rivet Actors: schedule.after and schedule.at timers survive restarts and crashes, plus re-arming recurring jobs and idempotent handlers.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Build an AI agent backend with persistent memory: one Rivet Actor per conversation, queued message handling, and streaming LLM responses as realtime events.
Build a realtime chat room backend with Rivet Actors: one actor per room, SQLite-backed message history, and WebSocket broadcast to every connected client.
Build a collaborative text editor backend with Yjs CRDTs and Rivet Actors: per-document actors relay sync and awareness updates and persist snapshots.
Live cursors and multiplayer presence with Rivet Actors: per-connection cursor state, realtime updates over events or raw WebSockets, and throttling.
Pragmatic patterns for building multiplayer games: matchmaking, tick loops, realtime state, interest management, and validation.
Multi-tenant data isolation with one Rivet Actor per tenant: the actor key is the tenant id, so each tenant gets its own isolated dataset and migrations.
| name | cron-jobs |
| description | Durable cron jobs with Rivet Actors: schedule.after and schedule.at timers survive restarts and crashes, plus re-arming recurring jobs and idempotent handlers. |
IMPORTANT: Before doing anything, you MUST read BASE_SKILL.md in this skill's directory. It contains essential guidance on debugging, error handling, state management, deployment, and project setup. Those rules and patterns apply to all RivetKit work. Everything below assumes you have already read and understood it.
If you need a reference implementation, read the raw working example code in these templates:
Patterns for running durable cron jobs and scheduled tasks on Rivet Actors. Actor schedules are persistent timers owned by the engine, so a job keeps its deadline through actor sleep, restarts, upgrades, deploys, and crashes.
Start from the working Scheduling example on GitHub. It implements a reminder service with one-shot timers, a React frontend, and live trigger events.
The full API is documented in Scheduling. There are two methods, both available on the actor context:
| Method | Behavior |
|---|---|
c.schedule.after(duration, actionName, ...args) | Runs the named action after duration milliseconds. |
c.schedule.at(timestamp, actionName, ...args) | Runs the named action at an exact epoch timestamp in milliseconds. |
Key properties:
c.schedule.after(delayMs, "triggerReminder", reminder.id).cancelReminder and triggerReminder actions implement exactly this.c.schedule is one-shot, so recurring jobs are built by having the scheduled action re-arm itself at the end of each run:
Arm the first run from onCreate or a setup action; after that, the action keeps the chain alive by rescheduling itself.
Re-arming with after measures the next run from the end of the current one, so the cadence drifts later by the job's runtime on every cycle. If runs must stay aligned to a fixed cadence, re-arm with c.schedule.at(c.state.lastRunAt + DAY_MS, "runReport") instead.
The Scheduling example itself only uses one-shot reminders. A real re-arm implementation lives in the idle world actor, where the collectProduction action credits production, updates lastCollectedAt, and calls a scheduleCollection helper that re-arms with c.schedule.after(delayMs, "collectProduction", { buildingId }). It also shows catch-up handling: if the action runs late, it computes how many whole intervals elapsed since the last run and credits them in one batch before re-arming.
For multi-step jobs that need retries and progress tracking inside a single run, consider Workflows instead of chaining schedules.
| Approach | Timer Durability | Horizontal Scaling | Deploys And Restarts |
|---|---|---|---|
setTimeout / setInterval | In-process memory only | Every replica arms its own timer, so jobs run once per instance | All pending timers are lost on restart or crash |
node-cron and similar libraries | In-process memory only | Every instance runs the job unless you add external locking | Schedule resets on deploy; runs missed during downtime are skipped |
| External cron service | Lives outside your app | Needs a public HTTP endpoint plus its own dedupe and retry state | Survives your deploys but is separate infrastructure to operate |
| Rivet Actor scheduling | Persisted by the engine as a durable timer | Exactly one actor per key, so the timer is armed once rather than once per replica | Survives actor sleep, restart, upgrade, and crash |
A scheduled action can fire more than you expect: a crash between doing the work and re-arming can cause the action to run again, and because schedules cannot be cancelled, an action can fire for an entry that was already removed. Design handlers so a duplicate firing is harmless:
lastRunAt timestamp or a sequence number in actor state and update it inside the action. On each firing, compute elapsed time since the marker and skip or batch accordingly. The idle world actor's collectProduction does this with lastCollectedAt and whole-interval batching.triggerReminder looks the reminder up in c.state.reminders first and returns with a warning if it is gone, so a fire-after-cancel is a safe no-op.| Topology | Use When | Example Key |
|---|---|---|
| Singleton job actor | One global job such as a nightly report or cleanup pass | job["daily-report"] |
| Actor per scheduled entity | Per-user or per-resource timers such as reminders, trials, or billing periods | reminder[userId] |
The Scheduling example uses a single shared reminderActor["main"] key for demo simplicity. For production reminder systems, prefer one actor per user so timers, state, and load are isolated per entity. See Keys.
| Topic | Summary |
|---|---|
| Scheduling | One-shot timers armed with c.schedule.after(delayMs, "triggerReminder", reminder.id) or c.schedule.at(timestamp, "triggerReminder", reminder.id). |
| State | JSON state holding reminders and completedCount; the scheduled action mutates state when it fires. |
| Events | triggerReminder broadcasts a reminderTriggered event to all connected clients. See Events. |
| Cancellation | cancelReminder only removes the reminder from state; the scheduled action may still fire and no-ops via a state lookup guard. |
Actors
reminderActor["main"]c.schedule, marks reminders completed when the scheduled action fires, and broadcasts reminderTriggered to connected clients.scheduleReminderscheduleReminderAttriggerRemindergetReminderscancelRemindergetStatsreminderscompletedCountLifecycle
sequenceDiagram
participant C as Client
participant R as reminderActor
participant E as Engine
C->>R: scheduleReminder(message, delayMs)
R->>E: schedule.after(delayMs, triggerReminder, id)
Note over E: schedule persisted + alarm armed
R-->>C: reminder
Note over R: actor sleeps
E->>R: alarm fires, actor wakes
Note over R: triggerReminder(id) runs
R-->>C: reminderTriggered event
Note over R: recurring jobs re-arm here with schedule.after
The example is intentionally open: any client can connect to the shared ["main"] key and schedule or cancel anything. Treat all of the following as required extensions for production:
delayMs and timestamp from clients. Reject negative delays, timestamps in the past, and absurdly far-future deadlines, and bound message or payload sizes.scheduleReminder that internally arm a fixed callback. Do not pass a client-supplied action name or unchecked args into c.schedule.reminders array grows without bound. Remove or archive completed entries so state stays small.crypto.randomUUID() rather than timestamp-plus-random strings.