Docs Overview

CronCommander adds a control plane on top of cron. Instead of SSHing into servers, you get a unified view of all jobs, executions, and changes across your infrastructure.

Architecture arrow_forward

How the control plane works: components, data flow, and execution tracking.

Requirements arrow_forward

Supported platforms, architectures, and what your servers need to connect.

Security arrow_forward

How CronCommander protects your infrastructure. No remote execution, no surprises.

Roles & Ownership arrow_forward

Launch access boundaries, job accountability, and the post-launch governance roadmap.

Troubleshooting arrow_forward

Common issues, recommended checks, and solutions for the agent.

Quick Start

Connect an approved early-access workspace to the control plane.

The v2.3.0 binaries and adjacent SHA-256 checksums are published in GitHub Releases. The installer verifies the checksum before replacing an existing agent binary.
1

Get your API Key

Request early access. After your workspace is provisioned, copy its Workspace API Key from Settings.

2

Install the Agent

Run the universal installer on your Linux server. Replace YOUR_API_KEY with the key from Step 1.

Option A: Using Curl

curl -sSL https://croncommander.com/install.sh | CC_API_KEY=YOUR_API_KEY bash

Option B: Using Wget

wget -qO- https://croncommander.com/install.sh | CC_API_KEY=YOUR_API_KEY bash

The installer downloads the adjacent SHA-256 checksum and refuses to install a binary that does not match. Default installation runs in User Mode. Use --configure-as-root for system-wide access.

Manual checksum verification for v2.3.0

curl -fsSLO https://github.com/croncommander/cc-agent/releases/download/v2.3.0/cc-agent-2-3-0-linux-amd64
curl -fsSLO https://github.com/croncommander/cc-agent/releases/download/v2.3.0/cc-agent-2-3-0-linux-amd64.sha256
sha256sum -c cc-agent-2-3-0-linux-amd64.sha256

Production host verification

curl -fsSLo /tmp/croncommander-verify-install.sh https://croncommander.com/verify-install.sh
less /tmp/croncommander-verify-install.sh
sudo EVIDENCE_FILE=/secure/release-evidence/agent-install.md bash /tmp/croncommander-verify-install.sh --restart

Inspect the script before running it. Verification compares the installed binary with the published checksum, checks service ownership and permissions, then restarts the agent once and confirms boot enablement. The mode-0600 evidence file never includes the workspace API key.

3

Define your First Job

In the dashboard, click "Add New Job". Give it a name (e.g., "Database Backup") and set your schedule. The dashboard will generate a wrapper command for you.

Expert Tip

If you selected "Managed Sync" during setup, just wait—the agent will automatically write the job to your server within seconds.

4

Verify & Track

Wait for the first execution. You’ll see a green checkmark in the Executions view. Click it to see exactly what happened — without logging into the server.

Architecture

A simple architecture. No magic. Just reliable infrastructure for controlling cron.

Three Components, One Control Plane

CronCommander is built from simple, focused pieces. Each does one thing well.

memory

cc-agent

A single Go binary that runs on your servers. It wraps your cron jobs, captures their output, and reports back — so you never have to SSH in to check if something ran.

daemon — polls securely, syncs jobs
exec — wraps and reports each execution
router

Gateway

The single point of contact for all agents. Handles registration, polling, and durable execution reports over authenticated HTTPS.

Returns changed job definitions when agents poll after you create or update jobs in the dashboard.

dashboard

Web Console

The web interface where you see everything. Your agents, your jobs, every execution, and every change. One place for complete operational visibility.

Define jobs centrally. Changes propagate to agents automatically. No more SSHing to update crontabs.

Execution Flow

  1. 1 You create a cron job in the dashboard
  2. 2 Each agent polls the gateway and downloads the changed manifest
  3. 3 Each agent writes the job to /etc/cron.d/croncommander
  4. 4 When cron fires, it runs cc-agent exec
  5. 5 The exec wrapper captures output, timing, and exit code
  6. 6 Results are sent to the daemon, then to the gateway
  7. 7 You see the execution in your dashboard — within seconds

Your commands never leave your servers.

The agent runs your jobs locally. Only the metadata — what ran, when, and what happened — is reported back.

What Stays on Your Servers

The agent is intentionally minimal:

sync_alt

Works alongside cron

It doesn't replace cron — it wraps it.

block

No remote execution

Jobs are defined locally or via the dashboard.

shield

No root required

Runs as a dedicated user with minimal permissions.

timer

Lightweight heartbeat

Just a ping every 60 seconds — no constant phoning home.

code

Open and Inspectable

The agent is open source. The protocol is documented. You can read every line of code that runs on your servers.

View on GitHub open_in_new

Requirements

What you need to run the CronCommander agent across your fleet.

The automatic installer supports Linux with systemd, OpenRC, or SysV init. FreeBSD and macOS release binaries are available for manual installation and require an operator-managed service definition.

Supported Platforms

Linux

  • amd64 (x86_64)
  • arm64 (Graviton, RPi)
  • 386 (Legacy 32-bit)

FreeBSD

  • amd64
  • arm64

macOS

  • amd64 (Intel)
  • arm64 (Silicon)

Minimum Specifications

Runtime Resources

  • Disk: ~10 MB
  • Memory: ~20 MB RAM
  • Network: Outbound HTTPS (443)

Dependencies

  • Cron: Any standard impl (cron, cronie, dcron)
  • Tools: curl or wget, plus sha256sum or shasum
  • Optional: systemd for service management

verified_user Linux Installer Targets

Ubuntu 22.04+ Debian 12+ Rocky Linux 9 Fedora 40 Amazon Linux 2023 Alpine 3.19+

The published binary and checksum must match the host architecture. The automatic installer fails closed on unsupported kernels or init systems.

Roles & Job Ownership

CronCommander isolates accounts and workspaces and makes every managed job attributable to a user.

The launch baseline uses authenticated account membership and per-job ownership. Invitations, fine-grained account/workspace roles, team ownership, deactivation reassignment, Auditor access, and change approvals are post-launch roadmap scope.
Launch concept Scope Capabilities
Authenticated account memberOwn account and its workspacesUses the current launch feature set within strict client and workspace boundaries.
Job ownerOne managed jobRecords operational accountability. Ownership is not yet a permission boundary.

Plan availability

  • Free: one user.
  • Starter: up to four users.
  • Pro: up to 25 users.
  • Agency: unlimited users.

Post-launch governance roadmap

The target model adds invitations, scoped roles, Auditor access, and separation-of-duties approvals. These controls are not part of the launch baseline.

Ownership lifecycle

  1. Every new or imported managed job requires an eligible owner.
  2. CronCommander tracks the owner, creator, and last modifier separately.
  3. Authenticated account members can transfer ownership to another user in the same account.
  4. Team ownership and automatic reassignment after deactivation are post-launch work.
  5. Job deletion is soft deletion, preserving executions and audit history.

Activity and auditability

Ownership and operational events appear in the workspace Activity timeline. The compliance Audit Trail baseline provides authorized filtering, plan-aware retention, and CSV export. Approval events will be added with the post-launch approval workflow.

Security Model

How we protect your infrastructure through dual-mode isolation and execution hardening.

Design Philosophy: Defense-in-Depth

We assume commands can be malicious. We focus on limiting the blast radius rather than flawed character filtering. We do NOT filter shell metacharacters because such filters are easily bypassed and break legitimate automation.

1. User Mode (Default)

Principle: Least Privilege

The agent runs as cc-agent-user. It cannot modify system files or access root resources. It manages jobs via its own user crontab.

  • Job User: Always cc-agent-user
  • Risk: Low. Access limited to agent resources.

2. System Mode (Opt-in)

Principle: Operator Control

The agent runs as root to maintain system-wide cron definitions. Required for jobs needing root or cross-user execution.

  • Job User: Root or specified user
  • Risk: High. Use only in trusted environments.

security Execution Hardening

no_accounts No Login Shell

cc-agent-user has no login shell and the account is permanently locked.

enhanced_encryption GCP Native Encryption

All data in transit and at rest is secured via industry-standard native encryption.

policy NO_NEW_PRIVS

Sets execution flags to prevent privilege escalation via setuid binaries.

lock Restricted Path

Jobs execute with a ultra-minimal PATH=/usr/bin:/bin environment.

Troubleshooting & FAQ

Common issues and recommended checks when running the CronCommander agent.

Agent shows as "Offline" in the dashboard expand_more

Checks & Solutions:

  • Verify the daemon is running: systemctl status cc-agent or check the background process log (/var/log/cc-agent.log).
  • Check your API key in /etc/croncommander/config.yaml. If it is invalid, the server will reject the connection.
  • Ensure outbound access on port 443 (HTTPS) is allowed by your firewall. The agent must be able to reach the configured gateway URL.
Why is an enabled job marked "Over limit"? expand_more

Managed-job limits are applied per agent: 10 on Free, 25 on Starter, 100 on Pro, and unlimited on Agency. After a downgrade, CronCommander keeps every definition for recovery and auditability, marks deterministic excess jobs as Over limit, and excludes them from the agent manifest. Upgrade the plan or disable other jobs to make capacity available.

Executions aren't appearing in the logs expand_more

Checks & Solutions:

  • First, verify the job is actually triggering. Check your system's syslog or cron log (e.g., /var/log/syslog or /var/log/cron).
  • Ensure the job definition wraps your command with the agent. It should look like this: cc-agent exec --job-id '...' -- /bin/sh -c 'your command'.
  • If the job triggers but nothing appears in the dashboard, check the agent daemon logs for socket errors. The exec wrapper communicates with the local daemon via a Unix socket.
"Permission Denied" on cc-agent.sock expand_more

Checks & Solutions:

  • This happens when the agent daemon runs in System Mode (root), but a cron job attempts to execute as an unprivileged user who lacks access to /var/lib/croncommander/cc-agent.sock.
  • Solution: Either add the execution user to the cc-agent-user group, or install the agent in User Mode specifically for the unprivileged user.
How do I get an existing job into the dashboard? expand_more

CronCommander operates top-down. You must first create the job in the Web Console to generate a unique Job ID. Once created, the dashboard will provide the exact cron expression and cc-agent exec wrapper string that you can drop into your server's crontab (or the agent will sync it automatically if enabled).

Executions happened while the agent was offline—where are they? expand_more

If the agent loses connection to the server, it buffers execution reports locally. You can check the spool directory for pending JSON reports:

  • System Mode: /var/lib/croncommander/spool/
  • User Mode: ~/.croncommander/spool/ (e.g. /home/cc-agent-user/.croncommander/spool/)

The agent's retry worker automatically scans this directory every few minutes and flushes pending data once connectivity is restored.

What CronCommander Is Not

Understanding our scope helps set clear boundaries for where we provide the most value.

block

Not an RMM Platform

Unlike NinjaOne or Kaseya, we don't handle patching, device compliance, or remote desktop access. We focus exclusively on cron jobs as first-class objects.

account_tree

Not a Workflow Scheduler

We are not Airflow or Jenkins. We don't model complex DAGs, data pipelines, or multi-step, dependent build workflows.

Scope Comparison

CronCommander is not a monitoring service. It is a control plane. Here's how the scope differs from cron monitoring tools (like Cronitor or Healthchecks.io) and RMM platforms.

Capability CronCommander Cron monitoring
(Cronitor, Healthchecks)		 RMM platforms
(NinjaOne, Kaseya)
Primary abstraction Cron jobs as first-class objects Heartbeat pings Endpoints / devices
Global job inventory check_circleAutomatic discovery No — you register jobs manually Indirect
Execution logs (stdout/stderr) check_circleFull capture No — only ping/no-ping Varies
Managed cron (define & deploy) check_circleDefine once, deploy everywhere No — monitoring only No
Drift detection Roadmap — planned after launch No No
Deploy across hosts check_circlePush jobs to multiple servers No Script deployment (generic)
Job ownership check_circleAssigned per job No No
Change approvals Roadmap — planned after launch No No
Full audit trail check_circleEvery change, who, when No Partial (device-level)
Scheduling insights / AI Roadmap — not in launch baseline No No
Preserves native cron check_circleYes — wraps, doesn't replace Yes Often abstracted
Multi-client isolation check_circleWorkspace-level separation No Yes

Cron monitoring tells you if a job pinged. CronCommander tells you what ran, what it output, who owns it, and whether the server matches what you defined.