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.

Troubleshooting arrow_forward

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

Quick Start

Go from zero to full visibility in less than 2 minutes.

1

Get your API Key

Log in to the CronCommander Console. Create a new Workspace (e.g., "Production") and copy your Workspace API Key from the Settings tab.

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

Note: Default installation runs in User Mode for maximum security. Use --configure-as-root for system-wide access.

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 — maintains connection, syncs jobs
exec — wraps and reports each execution
router

Gateway

The single point of contact for all agents. Handles registration, heartbeats, and receives execution reports in real-time via WebSocket.

Pushes job definitions to agents whenever 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 The gateway pushes the job to connected agents
  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.

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) via WebSocket

Dependencies

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

verified_user Tested Distributions

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

Any POSIX-compliant environment with cron should work.

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/WSS) is allowed by your firewall. The agent must be able to reach croncommander.com.
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 check_circleAlert when servers diverge 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 check_circlePropose → Review → Deploy No No
Full audit trail check_circleEvery change, who, when No Partial (device-level)
Scheduling insights / AI check_circleCollision detection, optimization 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.