# CronitorCLI: a command line client for cron monitoring

> CronitorCLI is the Go companion application for the Cronitor.io monitoring service, and most of its substance is in the account plumbing rather than the cron commands: a browser login with a paste-back path for headless hosts, per-user config files with owner-only permissions, and credentials whose lifecycle is documented in unusual detail. The API side covers monitors, status pages and issues.

**cronitorio/cronitor-cli** — Command line tools for Cronitor.io

- Repository: https://github.com/cronitorio/cronitor-cli
- Website: https://cronitor.io/docs/using-cronitor-cli
- Stars: 553 · Forks: 41
- Language: Go
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/cronitorio-cronitor-cli

## A companion client for a hosted monitoring service

The README describes CronitorCLI as the recommended companion application to the Cronitor monitoring service, and says to use it on your workstation and deploy it to your server for powerful features.

The four features it lists are the summary of the whole product. You can import and sync all of your cron jobs with Cronitor. You can easily manage your cron jobs with the web-based control panel, which the README links as the Crontab Guru Dashboard. You get automatic integration with Cronitor. And you get power tools for your cron jobs.

So the tool has two halves. One half talks to the Cronitor API, and the other half runs things locally, and it is a Go program with a single executable for Linux, MacOS and Windows.

The shape of the interface is conventional:

```
cronitor [command]
```

Installation is either a script or a download. CronitorCLI is packaged as a single executable for Linux, MacOS and Windows, and the README says there is a simple installation script, but that all you need to do is download and decompress the app into a location of your choice for easy system-wide use. The full installation details live at cronitor.io/docs/using-cronitor-cli, which is also the homepage of the project.

The repository is Go, with the module named github.com/cronitorio/cronitor-cli and a go directive of 1.26.2. The licence is recorded as one GitHub cannot classify, with a LICENSE file in the repository root. The recent releases are 33.9 from 2026-10-08, 33.8 from 2026-09-30 and 33.7 from 2026-09-18, and the last push was on 2026-10-22.

## The login flow, and the paste-back path for headless hosts

Authentication is where most of the README's length goes, and for good reason: a CLI that has to run on a server has to authenticate without a browser.

The local flow opens a browser using authorization code + PKCE. You sign in to your existing Cronitor account, or create one in the same browser step with Google, GitHub, or email and password, and after approval the CLI saves a named machine credential for this installation. `cronitor signup` is an alias for `cronitor auth login`.

For remote terminals or agents there is the other path. Run `cronitor auth login --no-browser`, keep the process running while the human opens the displayed authorization URL and completes sign-in or signup, then copy the entire resulting URL from the browser address bar and paste it into the waiting CLI prompt, where input is hidden. The browser will redirect to `http://127.0.0.1:8319/callback` and may show a connection error because the CLI is on another computer, and the README is emphatic that no SSH tunnel is needed.

The details that matter operationally are these. Local login listens only on `127.0.0.1:8319` and receives the callback automatically, so if that port is occupied you close the other login attempt or use `--no-browser`. The CLI waits 30 minutes by default and prints that local deadline next to the authorization URL, and after you open the link you are asked to finish signing in within about 5 minutes, with `--timeout` available to wait longer, for example `--timeout 2h`. Starting a new login replaces the previous URL.

And there is a version constraint with a reason. These instructions require version 33.7 or later, because version 33.6 used a device flow that is incompatible with the authentication provider's External Sign-in. Existing API keys continue working, and you should upgrade to 33.7 or later for browser login.

One instruction is a security instruction and deserves repeating. Paste this URL only into that prompt, not an agent conversation, because it contains a short-lived authorization code. Never share passwords, API keys, or tokens.

## Config file ownership is a deployment decision

The next part of the README is about who owns the credential file, and it reads like a note written by someone who has been burned.

Use a writable config owned by the OS user that will run the CLI. For a fresh Linux/macOS installation without a writable system config:

```bash
mkdir -p "$HOME/.config/cronitor"
export CRONITOR_CONFIG="$HOME/.config/cronitor/cronitor.json"
cronitor auth login --no-browser
cronitor auth status
```

The instruction afterwards is to keep using that config path, through `CRONITOR_CONFIG` or `--config`, for subsequent commands. That matters because the file is created with restricted permissions and because the path is where the credential lives.

Login restricts the saved file to its owner, `0600` on Unix, and an owner-restricted ACL on Windows. So the consequence follows directly: jobs running as another OS user need their own config or credentials supplied through their service environment.

That is the deployment shape the tool expects. A monitoring agent that runs as a dedicated service account has its own configuration, not the operator's, and a job that runs as a different user cannot borrow the operator's credential. Setting CRONITOR_CONFIG in a unit file or an environment for the service is the mechanism, and the permission model means two users on the same machine are two separate authentications unless the credential is deliberately passed along.

The auth status command is the read-only counterpart, and it is designed to be safe to run in scripts. `auth status` shows the credential's organization and permissions without exposing the key.

## Credentials have a lifecycle, and the README is unusually explicit about it

Two paragraphs here are worth reading closely, because most CLI documentation stops at the login.

The first is about what a credential can do. Full-access users receive SDK Integration credentials, and read-only users receive telemetry-only credentials and cannot manage account resources. The practical effect is that a teammate with read-only access can install the CLI and monitor their own jobs but cannot create a monitor or a status page through it, and the CLI will not be the place that fails. The advice that follows is to reuse working credentials rather than logging in again for every task, which is both faster and avoids accumulating keys.

The second is about logout, and it is a warning rather than a description:

```bash
cronitor auth logout
```

Logout revokes this installation's credential and removes it locally, and the bolded consequence is that scheduled jobs using that credential will stop authenticating. Agents should not log out as routine task cleanup.

The remaining sentences describe how the credential actually lives, and they are the part most people find surprising. The credential persists independently of the browser session, so closing the browser or signing out elsewhere does not touch it. Removing a user or changing their role does not automatically revoke it. And replacing a credential with another login does not revoke the previous key, so unused keys have to be removed in the dashboard.

In other words, the CLI is not the source of truth for what is authorised. The dashboard is. That is a sensible design, since a credential that could revoke itself would be a weak revocation mechanism, but it does mean an audit of who can access the account has to happen in the dashboard rather than by listing the config files on your machines.

## The resource commands are a complete API client

The cron management commands are short:

```
| `cronitor sync` | Sync cron jobs to Cronitor |
| `cronitor exec <key> <cmd>` | Run a command with monitoring |
| `cronitor list` | List all cron jobs |
| `cronitor status` | View monitor status |
| `cronitor dash` | Start the web dashboard |
```

Sync pushes your cron jobs to Cronitor, exec runs a command with monitoring attached, list and status report on the local jobs, and dash starts the web dashboard from the terminal.

Beyond that, the README documents the API resources, and the coverage is broad. For monitors, you can list them all, filter by type and state such as `--type job --state failing`, filter by tag and environment with `--tag critical --env production`, export the full YAML configuration with `cronitor monitor export -o monitors.yaml`, search for a monitor by name, get one with its details or with the latest events included, create one from an inline JSON document or from a YAML file, update, delete one or many, clone, and pause a monitor indefinitely or for a fixed number of hours before unpausing it.

Status pages have their own commands, including a component list nested under a status page and the creation of a component bound to a monitor, so a status page can reflect the state of an existing monitor.

Issues are the third group, with filtering by state and severity, by monitor and time range, and by free-text search, plus create, update and a resolve shorthand.

The YAML export and the `--file` create are the two features that matter most for infrastructure as code. Export gives you the current state of every monitor in a file you can commit, and create from that file turns a review into a deploy, which is a workflow you would otherwise have to build around the JSON API by hand.

## A Go client with a terminal UI and an MCP server

The dependency list in go.mod describes the implementation, and a few entries stand out.

The command line is cobra with pflag and viper for configuration, and the output formatting uses tablewriter and fatih/color. Prompts use promptui, and kballard/go-shellquote is there to quote arguments correctly when a command is passed through to a shell, which is the kind of dependency that only earns its place by preventing an argument injection.

The terminal interface is built with the Charm libraries, bubbletea for the program model and bubbles for the widgets, with lipgloss for styling, and there is an MCP dependency, mark3labs/mcp-go, which points to the tool exposing its capabilities over the Model Context Protocol.

There are also two dependencies worth noticing for what they signal. getsentry/raven-go is a Sentry client, so the CLI can report its own errors to a Sentry project, and capnspacehook/taskmaster is a process supervisor, which is how `cronitor exec` runs and supervises the command it is monitoring.

The repository layout supports the two-halves design. There is cmd/ and internal/ for the CLI itself, lib/ for shared code, bin/ for the built binary, web/ for the dashboard assets that `cronitor dash` serves, docs/, fixtures/ and testdata/ for tests, plus a dockerfile with docker-compose.yml and compose.dashboard.yml.

The compose file defines two services for local work, a linux service built from the repository and an alpine service using the alpine:latest image, both with restart policies, both adding the SYS_PTRACE capability and both mounting the working directory at /cronitor, with commands that keep the containers alive. The ptrace capability is what lets a container inspect the traced process, which is how the monitoring of a running command works across a container boundary.

## Conclusion

CronitorCLI fits an operator who already uses Cronitor.io and wants to script against it, or who deploys monitoring agents onto servers that have no browser and no SSH tunnel to one. It is the wrong choice if you are not a Cronitor customer, because the tool exists to talk to that service and to nothing else, and it is the wrong choice for a team that wants its cron state checked by an open source service. Verify first which credential your account will be issued, because a read-only user gets telemetry-only credentials that cannot manage account resources, and confirm which OS user will run the CLI, since the config file is created with owner-only permissions and a job running as another user needs its own.

## FAQ

### What does CronitorCLI do?

It is the recommended companion application for the Cronitor monitoring service. It can import and sync cron jobs with Cronitor, manage those jobs through the web-based control panel, integrate automatically with the service and provide monitoring tools for the commands themselves.

### How do I log in to CronitorCLI on a server with no browser?

Run cronitor auth login --no-browser, open the displayed authorization URL on a machine that has a browser, and copy the entire resulting URL back into the waiting CLI prompt, where the input is hidden. The browser will try to reach http://127.0.0.1:8319/callback and may show a connection error, which is expected, and no SSH tunnel is needed.

### Which CronitorCLI version is needed for browser login?

Version 33.7 or later. The README says version 33.6 used a device flow that is incompatible with the authentication provider's External Sign-in, and that existing API keys continue working, so the upgrade is only needed for the browser login path.

### Where does CronitorCLI store its credential and what permissions does it use?

In a config file whose path comes from the CRONITOR_CONFIG environment variable or the --config flag, with the default under the user's config directory. Login restricts the saved file to its owner, 0600 on Unix and an owner-restricted ACL on Windows, so jobs running as a different OS user need their own config or credentials supplied through their service environment.

### What happens if I run cronitor auth logout?

Logout revokes that installation's credential and removes it locally, and the README warns in bold that scheduled jobs using the credential will stop authenticating, and that agents should not log out as routine cleanup. The credential also survives the browser session and role changes, so unused keys have to be removed in the dashboard.

## Sources

- [cronitorio/cronitor-cli on GitHub](https://github.com/cronitorio/cronitor-cli)
- [Issues](https://github.com/cronitorio/cronitor-cli/issues)
- [Project website](https://cronitor.io/docs/using-cronitor-cli)
- [README](https://github.com/cronitorio/cronitor-cli/blob/master/README.md)
- [Releases](https://github.com/cronitorio/cronitor-cli/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cronitorio-cronitor-cli