Crontab UI

Last reviewed Sep 13, 2026 · 806 words

Twelve jobs on one box is the sweet spot for Crontab UI. Below that, crontab -e is fine; above that, or across 3 hosts, you want a real scheduler. In its sweet spot it fixes the two things about cron that cause outages: nobody can see what ran and whether it failed, and one mistyped asterisk in a hand-edited file silently disables everything. It is a small Node app, uses about 100 MB, stores nothing in a database, and has been maintained at a steady pace since 2016.

What it wraps: the real crontab, not a copy

Crontab UI keeps its own list of jobs in a small file-based store and writes them out to the actual system crontab of the user it runs as. The Import button pulls an existing crontab into the UI so you can adopt a host without retyping. Each job gets a name, a schedule, a command, a logging toggle, and an enable switch, and the app wraps the command so stdout and stderr land in a per-job log file you can read from the browser. There is a Run Now button, which sounds trivial and is the feature that gets used most. Backups are a button too: it snapshots the job store and lets you restore a previous state, which covers the "I just deleted the backup job" case.

Docker versus bare metal is a real decision here

On bare metal, npm install -g crontab-ui and crontab-ui on port 8000, run as the user whose crontab you want to manage. Jobs execute on the host with that user's PATH and can call anything installed there. In Docker, the picture changes:

services:
  crontab-ui:
    image: alseambusher/crontab-ui
    environment:
      BASIC_AUTH_USER: admin
      BASIC_AUTH_PWD: pick-a-real-one
      CRON_IN_DOCKER: "true"
    volumes:
      - ./crontabs:/crontab-ui/crontabs
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "8000:8000"

Inside the container, jobs run inside the container. Your restic binary, your rsync to a NAS, your Python script in /opt, none of them exist in there. The usual fix is to mount the Docker socket and write jobs as docker exec other-container some-command, or docker run a one-shot image, which is what the socket mount in the example enables. That is workable, and it is how I run it, but it makes the Crontab UI container root-equivalent on the host, so the password in BASIC_AUTH_PWD becomes a host credential. Treat it that way.

Put it behind auth before anything else

The app ships with no authentication unless you set BASIC_AUTH_USER and BASIC_AUTH_PWD. An unauthenticated Crontab UI is a remote shell with a nice layout, so either set those variables or put it behind your reverse proxy's auth and bind the port to 127.0.0.1 only. Add the log directory to your backups; the logs are also the audit trail for what ran when, which is useful the day a backup job quietly stopped in March and you notice in August.

Where it stops: one host, plain cron syntax

Crontab UI is scoped to the one crontab it manages. It has no notion of agents on other machines, no dependency between jobs, no retries, no alerting when a job fails, and no timezone handling beyond what the host's cron does. For the failure-alert half of that list, pair it with Healthchecks: append && curl -fsS https://hc.example.com/ping/uuid to each command and you get a message when a job does not check in. For the rest, Cronicle is the bigger project in the automation category with remote workers, chaining, retries and a proper event log; it is the safer pick as soon as a second host is involved. n8n and similar tools are a different category entirely, workflows rather than scheduled commands, and are overkill for "run this script nightly".

Who actually runs it

Home servers with a single Docker host, small companies with one utility box that runs report exports, and anyone who has inherited a crontab with 30 entries and no comments. Compared to plain cron it adds visibility, not capability, and that is the honest pitch: same scheduler, same syntax, same limits, with logs and a button.

What I'd do

On a single Docker host: the compose above, port bound to localhost, behind Caddy with the basic auth left on as a second layer, every job pinging Healthchecks. Jobs written as docker exec into the container that owns the tool, so the Crontab UI container stays a thin shell. The moment a second host shows up, move the jobs to Cronicle and keep Crontab UI only for the odd local task, because a scheduler that cannot see the other machine is a scheduler you will forget about.