Overview

Cronlet has two developer-facing surfaces:

1. Cronlet Cloud for hosted scheduled tasks, run history, callbacks, and agent-triggered automation.
2. cronlet local runtime + CLI for file-based jobs inside your own Node.js app.

Use Cronlet Cloud when

• your product needs hosted scheduled tasks
• AI agents should be able to create or manage schedules
• you want callbacks when runs complete
• you need a dashboard, task history, manual triggering, and hosted execution

Use the local runtime when

• jobs should live entirely inside your app repo
• you want file-based job discovery
• you do not need the hosted Cloud control plane
• you want local scheduler + dashboard during development

Recommended reading order

Cloud + SDK

1. Cloud Quickstart
2. SDK Overview
3. Tasks, Handlers, and Schedules
4. Callbacks and Agent Loops
5. Agent Tooling
6. SDK API Reference

Local runtime + CLI

1. Local Runtime Quickstart
2. Local Runtime Reference

Package map

• @cronlet/sdk: official Cloud SDK for tasks, runs, secrets, usage, audit, and LLM tool definitions
• @cronlet/shared: shared Cloud types and schemas used by the SDK and web app
• cronlet / cronlet-cli: local scheduler, file-based jobs, dev dashboard, and deployment helpers

Important accuracy notes

• The SDK accepts schedule objects and a constrained set of supported schedule strings.
• String schedules are parsed client-side into ScheduleConfig objects before the request reaches the API.
• Naive once datetime strings are interpreted as UTC unless the string includes timezone information.
• Cloud callbacks do not currently include a populated task.name, and stats.expiresAt is currently null in worker callbacks. Build callback handlers around task.id, task.metadata, and run.id.

If you are integrating Cronlet into a product, treat task.metadata + your own database records as the source of truth for ownership and lifecycle.