Cronmaster

Self-hosted cron job management, honestly reviewed. No marketing fluff, just what you get when you point a web browser at your crontab.

TL;DR

• What it is: A web UI that sits on top of your Linux server’s native cron daemon, adding a visual editor, live log streaming, and a REST API to the same crontab you’ve always had [1].
• Who it’s for: Developers and technically-comfortable founders running their own VPS who are tired of crontab -e and tail-ing log files to see what ran [1].
• Cost: $0 for the software (AGPL-3.0). Self-hosted on the same server that already runs your cron jobs. No SaaS tier exists [1].
• Key strength: Live log streaming via SSE — you can watch a long-running cron job in real time in your browser, which is genuinely useful when debugging [1].
• Key weakness: Requires privileged: true, pid: host, and runs as root by default in the recommended Docker config. That’s a meaningful security trade-off on any server you care about [1].
• Reality check: 1,112 GitHub stars and 29 forks as of this writing. Useful tool, but limited community and no track record of third-party production deployments to benchmark against [1].

---

What is Cronmaster

Cronmaster is a Next.js web application that wraps your Linux server’s existing cron daemon with a browser-accessible interface. The pitch is simple: instead of SSH-ing into your server, opening crontab -e in vi, and checking logs scattered across /var/log, you get a web UI with a job list, a schedule editor with human-readable syntax, and real-time log output [1].

The key architectural decision is that Cronmaster doesn’t replace your cron daemon. It reads and writes crontab files directly — which is why the Docker container needs root access and host PID namespace. You’re not switching schedulers; you’re adding a management layer on top of the one that already exists [1].

The project is maintained by a single developer (fccview), has been active for roughly 153 commits, and has a Discord server for support. The README is clean and the Docker setup is genuinely quick. It’s clearly a passion project that scratches a real itch — the issue is understanding exactly whose itch it scratches, and whether the trade-offs are acceptable for your situation.

---

Why People Choose It

There are no substantial third-party reviews of Cronmaster available. The GitHub star count (1,112) suggests a meaningful number of people found it useful, but the fork count (29) suggests most are running it as-is rather than building on it [1]. Community shouts appear in the GitHub README, which is the primary signal available.

The evident appeal from the feature set is straightforward: cron is ubiquitous, the tooling around it is stuck in the 1970s, and nothing in between “raw crontab -e” and “full workflow automation platform like n8n” has gotten mainstream adoption. Cronmaster fills that gap with minimal overhead.

The closest analogy is what Portainer did for Docker — not a replacement, just a UI layer that makes the existing tool accessible without SSH. If that framing resonates, Cronmaster will probably make sense for your setup. If you need scheduling that works independently of a Linux crontab (containerized environments with no host cron, Windows servers, multi-host setups), you’re looking at the wrong tool.

---

Features

Based on the README and repository [1]:

Core job management:

• View, create, and delete cron jobs via web UI [1]
• Human-readable schedule presets (“every day at midnight”, “every 5 minutes”) alongside raw cron expression editing [1]
• Comments on jobs — useful for remembering what 0 3 * * 0 /usr/bin/weird-script.sh actually does [1]
• Direct read/write access to the host crontab via Docker volume mount [1]

Logging and monitoring:

• Optional per-job logging that captures stdout, stderr, exit codes, and timestamps [1]
• Live log streaming via Server-Sent Events (SSE) — you can tail a running job in your browser [1]
• Automatic log cleanup to prevent unbounded disk usage [1]
• Smart execution mode: jobs with logging enabled run in the background with live updates; jobs without logging run synchronously with a 5-minute timeout [1]

System visibility:

• Dashboard showing server uptime, memory usage, network stats, CPU, and GPU info [1]
• Real-time clock updates via configurable polling interval [1]

Scripts:

• Built-in bash script manager — create, view, and delete scripts that your cron jobs can call [1]
• Scripts stored in a mounted volume (./scripts:/app/scripts) [1]

Access and integrations:

• Password-based authentication with session management [1]
• OIDC/SSO support for any compliant provider: Authentik, Auth0, Keycloak, Okta, Google, Microsoft Entra ID [1]
• REST API with optional API key authentication for external integrations [1]
• Responsive UI with dark and light mode [1]
• ARM64 and AMD64 support — runs on Raspberry Pi [1]
• Localization support with community-contributed translations [1]

What it doesn’t do:

• No retry logic for failed jobs
• No alerting or notification on job failure (no email, no webhook)
• No job dependencies or chaining
• No multi-server support — one instance manages one server’s crontab
• No audit log of who changed what (relevant if multiple people have access)

---

Pricing: SaaS vs Self-Hosted Math

Cronmaster has no SaaS offering and no paid tier. The software is free under AGPL-3.0 [1]. The relevant cost comparison is against paid cron monitoring and management services that solve adjacent problems:

Cloud-based cron monitoring alternatives (monthly, billed annually):

• Cronitor: $29/mo for the Starter plan (5 monitors), up to $99/mo for business tiers
• Cronhub: $19/mo for 10 monitors
• Healthchecks.io: $20/mo for 20 checks, $80/mo for 100 checks

These services primarily do monitoring (did your job run? did it fail?) rather than management (scheduling, editing, log viewing). They complement cron rather than replacing the UI around it.

Cronmaster self-hosted:

• Software: $0
• Compute: $0 additional — runs on the same server your cron jobs already run on
• Storage: minimal — logs accumulate but auto-cleanup is configurable [1]

If you’re paying $20–100/month for a hosted cron monitoring service and still SSH-ing in to manage the actual schedule, Cronmaster addresses the management half of that equation at zero marginal cost. The monitoring half (did it run? alert me if it didn’t) is outside Cronmaster’s scope — you’d still want Healthchecks.io or similar for failure alerting.

For a founder running 10–20 scheduled tasks on a VPS: the incremental cost of Cronmaster is zero. The value is purely the time saved not SSH-ing in to check logs.

---

Deployment Reality Check

The Docker Compose setup is genuinely quick. You copy the provided docker-compose.yml, set three environment variables, and run docker compose up -d. The application is accessible on port 40123 by default [1].

What the default config requires [1]:

user: "root"
privileged: true
pid: "host"
volumes:
  - /var/run/docker.sock:/var/run/docker.sock

This is the part worth pausing on. Running a web-accessible container as root with privileged: true and host PID namespace means a container escape would have full access to the host system. On a server running nothing but your own workloads, this is an acceptable trade-off. On a shared server, a hosting environment where containers are the security boundary, or anywhere that a breach would be consequential — this configuration is a meaningful risk.

The architectural reason is legitimate: reading and writing the host crontab from inside a Docker container requires this level of access. The project isn’t being cavalier about it; it’s the only practical way to interact with the host cron daemon. But the trade-off is real and should be a conscious decision, not an oversight [1].

What you actually need to deploy:

• A Linux VPS with Docker and Docker Compose installed
• The same server your cron jobs run on (Cronmaster manages that server’s crontab)
• A reverse proxy (Caddy or nginx) if you want HTTPS and a domain instead of accessing by IP:port
• Optionally: an OIDC provider if you want SSO instead of the password login

What can go sideways:

• Jobs that run fine locally may behave differently under Cronmaster’s background execution mode — the logging path runs jobs differently than synchronous execution [1]
• The 5-minute timeout on synchronous jobs (those without logging enabled) will silently fail anything that takes longer [1]
• No built-in alerting means you won’t know a job failed until you check the UI

Realistic setup time: 15–30 minutes for someone comfortable with Docker Compose. Add another 30 minutes if you’re setting up a reverse proxy from scratch.

---

Pros and Cons

Pros

• Zero friction on familiar infrastructure. If you already run Linux with cron, you add one Docker container and your existing cron jobs appear in a UI. No migration, no new scheduler to learn [1].
• Live log streaming is genuinely useful. Watching a long-running job in real time beats tail-f’ing a log file over SSH [1].
• SSO included, not gated. OIDC support (Authentik, Google, Okta, etc.) is available in the free, self-hosted version — not locked behind a commercial tier [1].
• REST API ships in the box. Programmatic job management and triggering is available without a separate service [1].
• ARM64 support. Runs on Raspberry Pi and other ARM hardware — useful for homelab setups [1].
• Script manager included. Managing the scripts your cron jobs call is part of the same interface, which reduces the number of SSH sessions you need [1].
• Dark mode. Small thing, but the UI is clearly cared about based on the screenshots [1].

Cons

• Runs privileged as root. The recommended configuration requires privileged: true, pid: host, and user: root. This is an architecturally necessary trade-off, not sloppy engineering, but it’s a real security consideration [1].
• No failure alerting. Cronmaster will show you that a job failed — after you open the UI and look. It won’t tell you. For anything business-critical, you need a complementary monitoring service [1].
• Single-server, single-crontab. One Cronmaster instance manages one server. If you have jobs distributed across multiple servers, you’re running multiple instances with no unified view [1].
• AGPL-3.0 license. More restrictive than MIT. If you’re embedding this in a commercial product or SaaS, AGPL requires you to open-source your application. Fine for internal tooling, problematic for resale [1].
• Small project, one maintainer. 1,112 stars and 29 forks. No third-party audits, limited community documentation, Discord as the primary support channel [1]. A project this size can go quiet without warning.
• No retry logic. A failed job stays failed. No configurable retry policy [1].
• No job history beyond logs. There’s no timeline view of “job X ran 47 times last month, succeeded 44 times.” The logging captures individual runs; the aggregation isn’t there [1].

---

Who Should Use This / Who Shouldn’t

Use Cronmaster if:

• You manage a personal VPS or homelab server with existing cron jobs and want a web UI instead of SSH sessions.
• You’re comfortable with Docker and understand the privileged container trade-off.
• You want live log streaming for long-running scripts without setting up a full observability stack.
• You’re a solo developer or small team where SSO + password auth covers your access control needs.
• The AGPL license is compatible with your use case (internal tooling, not resale).

Skip it if:

• Your server handles sensitive data and privileged: true is a non-starter.
• You need failure alerting — use Healthchecks.io for that, either alone or alongside Cronmaster.
• You’re managing cron jobs across multiple servers and need a unified view.
• You’re building scheduled tasks into a product and need retry logic, job dependencies, or SLA monitoring.
• You want to embed or redistribute this in a commercial product — AGPL makes that complicated [1].

Consider something else if:

• You want scheduling that works without a host Linux cron daemon (containerized environments, Kubernetes) — look at Ofelia or Kubernetes CronJobs.
• Your “cron job” problem is really a workflow automation problem (chaining tasks, conditional logic, external triggers) — look at n8n or Activepieces.
• You need multi-user access control with audit logs for a team larger than a handful of people.

---

Alternatives Worth Considering

Ofelia — Docker-native job scheduler that manages scheduled containers without touching the host crontab. Better architectural fit for containerized environments where host cron access is the wrong approach. Less UI polish.

n8n — Full workflow automation. Massive overkill if you just want to run a backup script every night, but the right answer if your “cron job” is actually a multi-step workflow with conditionals and external API calls.

Activepieces — Similar positioning to n8n. MIT-licensed, cleaner UI, growing integration catalog. Same caveat: overkill for raw script scheduling.

Healthchecks.io — Does the monitoring half that Cronmaster doesn’t: alerts you when a job fails or doesn’t run on schedule. Complementary rather than competitive. Self-hostable or managed cloud.

Crontab Guru — The cron expression explainer at crontab.guru. Not management software, but the go-to tool for understanding what 0 2 * * 1-5 means before you deploy it.

Raw crontab + journald/logrotate — For the majority of VPS users, crontab -e plus journalctl -u cron is already sufficient. Cronmaster is a quality-of-life upgrade, not a necessity.

---

Bottom Line

Cronmaster is exactly what it says it is: a modern UI for a daemon that hasn’t had one in 50 years. The live log streaming is the standout feature — if you’ve ever SSH-d into a server to watch a backup script run, you’ll immediately see the value. The security trade-offs are real but documented, and the decision to run privileged: true should be made with eyes open, not skipped over.

The project’s main risk isn’t the software itself, which is polished and functional for its scope. It’s the project’s size: one maintainer, 1,112 stars, and no track record of production deployments at scale. If you’re comfortable treating it as a quality homelab tool with that caveat, it delivers. If you need something with enterprise backing or a proven production history, you’re in the wrong place.

For the non-technical founder specifically: if you have a developer or sysadmin handling your VPS, ask them to deploy this. If you’re managing your own server solo, the Docker setup is achievable in an afternoon. If you’ve never touched a Linux server, this isn’t your entry point — start with Healthchecks.io’s managed cloud to understand the problem before you self-host the solution.

---

Sources

1. fccview/cronmaster — GitHub repository and README (AGPL-3.0, 1,112 stars). https://github.com/fccview/cronmaster