Manage cron jobs with the CronLite Admin UI

Enable the Admin UI

For local development with Go and Docker installed, run the admin launcher from the repository. It starts PostgreSQL, applies its supported missing migrations, generates a temporary bootstrap token, and prints the Admin URL. Review the migration instructions for an existing database.

./scripts/admin-local.sh

• For a manual launch, apply all required migrations, set ADMIN_ENABLED=true and a long random ADMIN_BOOTSTRAP_TOKEN, then start CronLite.
• Open /admin/setup on a fresh installation to create the first namespace-scoped API key.
• Existing installations sign in with an existing API key; no data import is required.
• Remove the bootstrap token from the runtime environment after setup and use HTTPS in production.

Find jobs in the Job Control Center

Search by name, filter active or paused jobs, and use exact key=value tags. Table and board views show the current filtered page; numbered pagination keeps large fleets navigable. Schedules appear in plain language with the raw cron expression still available.

The timeline estimates the next occurrence of active matching jobs within 24 hours. It displays up to 50 jobs and examines at most 500 matching jobs, with a limit notice. These estimates are separate from persisted execution states.

Preview bulk actions before confirming

Select jobs and preview a bulk pause or resume. The server stores the preview before confirmation and skips jobs that changed after the preview. Individual results distinguish applied, unchanged, conflicting, unavailable, and failed operations. Repeated confirmation returns the stored results.

Saved views and bulk history are private to the API key and namespace. Sessions that share a key also share those views; CronLite does not model separate individual users. Pausing leaves existing executions intact, and resuming does not replay missed runs.

Inspect deliveries and manage access

The Runs and execution-history screens expose persisted statuses and delivery evidence. Job details provide configuration and individual actions. API-key management lets you create labeled keys, view last-use metadata, and revoke keys after confirmation.

Browser sessions are stored in PostgreSQL, survive restarts, and expire on idle or absolute lifetime limits. Revoking a key invalidates its sessions. Effective runtime settings can be inspected in Admin; server deployment settings are changed through environment variables and a restart.