Developer tools · Crontab generator
Crontabs contain hostnames, paths and tokens: why build them offline
· Why it matters
cron privacy browser-tools
The schedule is harmless; the command next to it rarely is. This post explains what a crontab line reveals, why the generator should not need a server, and how to verify that nothing leaves the browser.
The line you were about to paste — 0 */6 * * * curl -s https://internal.example/hook?token=… is a schedule plus a live credential
A full line such as `0 */6 * * * curl https://internal.example/hook?token=…` contains two very different data classes. The first five fields describe timing; the rest can reveal a private hostname and live credential. ToolAcre needs only the schedule, so sending the entire line expands exposure without improving validation.
Separate the fragment before pasting. `0 */6 * * *` is enough for parsing, description and next-run calculation. Keep the command in a controlled editor and replace any already-exposed credential through the system that issued it. A schedule tool cannot make a secret harmless after disclosure.
What a crontab exposes — hostnames, internal paths, usernames, API tokens in URLs and the shape of your operations
Commands commonly carry internal paths, account names, repository locations, query parameters and operational cadence clues. Even when no obvious token appears, a line can map the shape of a backup or maintenance process. The five timing fields reveal far less and are the only portion accepted by `parseCron`.
The browser UI’s placeholder full line reinforces that boundary: it appends `/usr/local/bin/your-command`, not text supplied by a command parser. There is no feature that inspects a real executable or URL. Deliberately limiting input reduces both accidental disclosure and false confidence about command safety.
Why a schedule generator needs none of it — building and explaining five fields is pure computation
Building and explaining this grammar is deterministic local computation. `cron.js` imports only a local error type, expands tokens in memory, uses `Intl.DateTimeFormat` for zone calculations and returns JavaScript data. The UI derives the sentence, warnings and five upcoming runs from that parsed object.
No schedule-generation endpoint appears in the implementation path. That finding supports browser-side operation for the feature reviewed here, but it is still better to inspect the deployed page’s network activity than rely on a generalized slogan. Other site resources or future code can create requests unrelated to expression parsing.
The implementation is browser-side and does not persist an expression itself
The panel starts with a default expression and synchronizes the whole-expression box with five per-field controls. It does not write the expression to storage in the reviewed module. Refresh behavior, browser extensions and hosting infrastructure are separate surfaces, so the claim stays tied to the source actually read.
There is no account field in the panel and no upload control. Copying uses a clipboard helper only after a button click. These facts justify a narrow operational practice: provide the schedule fragment, observe the result and avoid supplying sensitive command material the algorithm neither needs nor understands.
Verify runtime behavior from source and browser tools rather than accepting a blanket privacy slogan
Open browser developer tools and filter network activity while changing `0 */6 * * *` to another expression. The description and preview should update from local event handlers. Distinguish initial page assets from requests caused by editing; the relevant question is whether schedule input is transmitted when it changes.
Source inspection and runtime observation complement one another. The source shows no fetch in the panel or library, while the network panel checks the deployed artifact and surrounding page. If a future build behaves differently, trust the captured request evidence and re-audit rather than preserving an old privacy sentence indefinitely.
Worked example: separating schedule from command — building 0 */6 * * * in the generator and pasting only that into the crontab
For the example, retain `curl -s https://internal.example/hook?token=…` outside the browser. Enter `0 */6 * * *` alone. ToolAcre expands hour step values from 0 through 23 by six, describes the schedule and previews times in the chosen zone. Copy the expression, then reunite it with the command only in the controlled destination.
That workflow also improves debugging. If timing is wrong, the five fields can be shared without revealing the endpoint. If the request fails, command owners can investigate authentication separately. One redacted schedule becomes sufficient evidence for calendar review while secret-bearing details stay with the smallest necessary audience.
Server-side crontab permissions and secret storage remain out of scope
This repository does not manage permissions on crontab files, encrypt command arguments or rotate API tokens. It also cannot prevent secrets from appearing in process listings, shell history or host backups after deployment. Those risks require controls in the environment that stores and executes the line.
Do not misread local parsing as complete secret management. The privacy gain comes from data minimization: never give the generator the command. Review storage and execution separately, and use secret-delivery mechanisms documented by the target system rather than embedding credentials because the schedule portion was safely constructed.
Takeaway: give the tool the schedule, keep the command at home — and the generator is designed to work that way
A five-field expression is sufficient input for this route. Anything after it is unnecessary to its parser and may be sensitive. That makes separation the simplest privacy control: share timing for review, retain command details where operational access is already governed.
Use source inspection and a network-panel check to verify current behavior, then keep the habit even when a tool appears trustworthy. ToolAcre can construct, validate and explain a schedule without seeing what will run. The smallest useful input is both easier to audit and less costly to expose.