gocron: a web managed scheduler meant to replace crontab

What gocron is meant to replace

The project describes itself as a lightweight distributed scheduled task management system developed in Go, designed to replace Linux crontab. That framing tells you what problem it solves and, just as importantly, what it does not.

Crontab is good at one thing: running a command at a time on one machine. It has no interface, no history, no notification when a job fails, and no way to answer the question every team eventually asks, which is what ran last night and did it work. Gocron exists to sit in front of that model and give it a control plane. The README lists a web interface for task management, execution logs with auto-cleanup, and notifications by email, Slack and webhook.

The audience is operations teams and platform engineers who schedule work across several hosts. The distributed part is real rather than aspirational: there is agent auto-registration with one-click installation for Linux and macOS, so that task nodes join without manual configuration.

The implementation is a Go service with a web front end. The web directory in the repository is named gocronx-admin and the topics list mentions vue3 and vite, so the interface is a modern single page application served alongside the API rather than server rendered templates. The go.mod pins Go 1.26.6 and pulls in gin for the HTTP layer, gorm with MySQL and PostgreSQL drivers, logrus for logging, urfave/cli for the command line, golang-jwt for tokens, pquerna/otp for one-time passwords and grpc.

That dependency list already tells you what the product is: a multi-user web application with scheduling, authentication and a database, not a drop-in cron replacement file.

Leader election through database locks

Running more than one scheduler against the same set of tasks is the classic way to get duplicate job runs, so gocron addresses it directly. The README describes high availability as database-lock-based leader election with automatic failover in seconds, and states that leader election is automatic with no extra configuration.

The deployment model is straightforward. You run multiple gocron instances pointing at the same MySQL or PostgreSQL database, and only the leader schedules work. If that instance dies, another takes over, and the failover is described as happening in seconds rather than at the next scheduled tick.

The two-node example in the documentation is as simple as it gets:

# Node 1
./gocron web --port 5920

# Node 2 (same database)
./gocron web --port 5921

Both nodes serve the web interface, each on its own port, and both connect to the same database. The port difference matters only for local convenience, since in a clustered deployment a Kubernetes Service load-balances the web and API traffic.

The Helm chart runs in managed mode with two replicas by default, and the README explains that the database bootstrap is coordinated once and no shared persistent volume is required. SQLite remains available for standalone deployments, which is the single-instance case.

That split between SQLite and MySQL or PostgreSQL is the one architectural decision to make early. SQLite means a single node with a file on disk and no coordination problem. MySQL or PostgreSQL means you get failover and horizontal redundancy, and you take on the responsibility of running that database.

Second-level schedules and the cron parser it uses

Crontab's five-field expression has no seconds, which is the first thing teams hit when they want a job to run every thirty seconds or to line up precisely with a downstream job. Gocron supports crontab expressions with second precision, and its feature list calls this out as second-level precision.

The parsing itself comes from a separate module. The go.mod requires github.com/gocronx-team/cron v0.2.0, a fork maintained by the same team rather than an upstream cron library. That is worth noting when you evaluate the project, because schedule parsing is exactly the kind of code where edge cases around ranges, lists, steps and time zones decide whether a scheduler is trustworthy.

Around the parser, gocron adds the things a scheduler needs to be operable. Task retry is configurable, so a transient failure in a network call does not require a human to notice. Task dependency configuration lets one task wait for another. Execution logs are complete, with auto-cleanup so the database does not grow without bound, and live output is redacted and size-limited before being persisted across MySQL, PostgreSQL or SQLite.

Real-time task output is the feature that changes day to day work. The README describes streaming Shell (RPC) stdout and stderr in the execution output dialog while a job is running, with reconnect catch-up and acknowledged cancellation. In practice that means you can watch a long running script in the browser, and if your connection drops, the stream catches up rather than losing the output.

Starting it with Docker Compose

The documented fastest path builds the image from source locally with Docker Compose:

# 1. Clone the project
git clone https://github.com/gocronx-team/gocron.git
cd gocron

# 2. Start services
docker compose up -d

# 3. Access Web Interface
# http://localhost:5920

The compose file in the repository is short, and each line has a reason:

services:
  gocron:
    build:
      context: .
      dockerfile: Dockerfile.gocron
    image: gocron:latest
    container_name: gocron
    ports:
      - "5920:5920"
    volumes:
      - gocron-data:/.gocron
    environment:
      - TZ=Asia/Shanghai
    restart: unless-stopped

The build happens locally, so the image reflects your checkout rather than a published tag, which matters when you are testing a change. The named volume gocron-data mounted at /.gocron keeps state across container restarts, and restart: unless-stopped means the service comes back after a daemon restart.

The documentation recommends binary deployment for production, with the installation guide covering binary, Docker, Kubernetes and development setups. There is also an app.ini.sqlite.example file in the repository, which shows that configuration has an ini-style form for the SQLite case.

For a multi-node deployment you would run the same binary on each node with a --port flag, as in the two-node example, and point all of them at the same MySQL or PostgreSQL instance.

The AI and MCP surfaces, and what they cost you

Two of the more unusual entries in the feature list deserve a closer look before you decide whether to enable them.

The first is MCP support. The README describes remote management by AI clients, naming Claude Desktop and Cursor, through the Model Context Protocol, secured with web-managed access tokens. The go.mod confirms this is a real dependency rather than a description, since it requires github.com/modelcontextprotocol/go-sdk v1.6.1 along with grpc and protobuf.

What this means in practice is that an AI client connected to your scheduler can create, modify and inspect tasks. The access tokens are managed through the web interface, so revocation is a matter of deleting one. The trade-off is that the blast radius of a token compromise is your scheduling system, and the feature exists to let a model act, not merely to read.

The second is the AI assist block. The README lists natural-language to cron expression, AI-powered failure-log diagnosis, and an in-app AI ops chat assistant that can query tasks, logs, hosts and templates and diagnose failures. The important qualifier is at the end of that line: it is backed by any OpenAI-compatible model with a configurable endpoint, and it also works with self-hosted or local models.

That configurability is what makes the feature reasonable to evaluate. Pointing it at a local model keeps your logs and task definitions inside your own network, while pointing it at a hosted endpoint sends failure logs and scheduler state to that provider. The same reasoning applies to MCP, and it is the reason to read the configuration guide before turning these features on rather than after.

Access control, memory limits and the rest of the operational surface

A scheduler that runs commands as a service needs more than a cron table, and gocron covers several of the usual requirements.

Access control is described as comprehensive user and permission management, and there is two-factor authentication support, backed in the dependency list by golang-jwt for tokens and pquerna/otp for one-time passwords. Multi-database support covers MySQL, PostgreSQL and SQLite, with gorm as the object mapper and the MySQL and PostgreSQL drivers both present in go.mod.

One container-aware detail stands out. The README says the service automatically sets GOMEMLIMIT from the container's cgroup memory limit to reduce OOM kills in Docker and Kubernetes. That is a small thing with real consequences: a Go service that is killed by the kernel OOM killer at an arbitrary moment leaves a scheduler in an unknown state, and the dependency github.com/gocronx-team/memlimit is there to derive the limit from the cgroup rather than letting the Go runtime guess.

Notifications go out by email, Slack and webhook, and the go.mod includes gomail and grpc, with a webhook-test directory in the repository suggesting the webhook path is covered by tests.

The one thing to keep in mind is that this is a service with a database, a web interface and agents, and each of those is something you now operate. A crontab file has no dependencies and no leader election to reason about at three in the morning.

Licence, release cadence and the shape of the repository

The project is licensed under the MIT License, with the terms in the LICENSE file at the repository root. That is permissive enough to run internally without discussion, and it is not a licence that obliges you to publish anything derived from it, though your own review should confirm the position for your use.

The repository is not archived and the last push was on 2026-10-09. Recent releases include v1.12.0 on 2026-10-02, gocron-0.2.3 on the same day, and v1.11.1 on 2026-08-16. The two numbering schemes in that list suggest a separate versioning line for one component, which is worth noting if you script anything against release tags.

The tree shows the split between the Go service and the front end. There is a cmd directory for the command line, internal for the application code, web for the admin interface with the gocronx-admin project, helm for the chart, and a Dockerfile.gocron for the image. Tooling is a mix of Go and Node: golangci.yml for Go linting, and on the JavaScript side pnpm with packageManager [email protected], husky for git hooks, commitlint for message validation and prettier with eslint for formatting through lint-staged.

The contribution flow is documented and enforced. Commit messages are validated by a git hook, and the README asks contributors to use the interactive commit tool rather than git commit:

pnpm install      # first-time setup (installs git hooks)
pnpm run commit   # create a properly formatted commit

The upgrade cost for a team running this in production is mostly the database schema and the agent protocol across versions, and both of those change with releases that arrive every few weeks.

Editorial conclusion

Adopt gocron if your team runs scheduled jobs across more than one machine and wants one place to edit schedules, retry failures, watch live output and read logs, and if you are prepared to keep MySQL or PostgreSQL as the coordination database for a multi-node deployment. Do not adopt it if a single crontab line on one host is all you need, since the service, its agents and its web interface are more moving parts than that case warrants, and read the AI and MCP features carefully before enabling them. Before deploying, decide whether the tasks run on the gocron host or on registered agent machines, because the Shell RPC path and the agent model behave differently when the target is down.

Frequently asked questions

Official sources

1. gocronx-team/gocron on GitHub
2. License: MIT
3. Project website
4. README
5. Releases