Developer tools · Crontab generator
Where cron output goes: MAILTO, redirection and finding job errors
· How it works
cron observability developer-workflow
Cron mails output by default, which on most servers means it vanishes. This post explains MAILTO, stdout and stderr redirection, syslog and journalctl, so a failing job leaves evidence.
The job failed and left nothing — no log, no mail, no error, only a missing report
A report can be missing even though `0 0 * * *` parses, describes and previews correctly. Those signals establish midnight calendar candidates; they say nothing about stdout, stderr, a destination file or a notification channel. Changing the schedule to chase missing output risks creating a second problem without exposing the first.
Begin by preserving evidence. Save the exact five fields, selected preview zone and next-run list. Then investigate whether an action started and where its own results were directed on the target. ToolAcre is useful precisely because it lets the calendar half be checked independently of observability choices it does not implement.
A missing result can coexist with a valid expression and preview
The workbook described default mail delivery through a local agent. No mail code, daemon configuration or operating-system integration appears in the tool. The browser does not know whether a target host has mail transport, suppresses output or uses an entirely different scheduler. Repeating a default as universal would exceed the evidence.
Consult the actual implementation’s documentation and configuration. A schedule parser cannot infer output routing from five numeric fields. Two hosts may accept the same expression and treat command output differently. The article therefore frames mail as an external possibility to verify, not a promised destination.
Default mail behavior is not verified by this repository
`MAILTO` is not one of minute, hour, day of month, month or day of week. Entering an assignment in the expression box fails the exact-five-fields rule, and the per-field controls have no place for it. That is a scope boundary rather than a missing calendar feature.
Keep notification configuration beside the target crontab documentation, but do not expect the generator to parse or preserve it. A copied schedule contains only the expression. If a complete-file editor is needed, choose one that explicitly documents assignment handling instead of projecting that capability onto this route.
MAILTO is outside the expression grammar
Redirect operators and pipelines belong after the timing fragment. ToolAcre never sends them to a shell; its copy action uses a placeholder command to make that separation visible. Consequently it cannot validate append versus overwrite, descriptor ordering, file permissions or whether a logging command exists.
Review output handling as executable syntax on the destination. The five schedule fields can remain constant while redirect strategy changes. That independence is operationally useful: a team can improve logs without altering run times, and can adjust timing without accidentally rewriting the mechanism that captures failures.
Redirection belongs to the command, not the schedule
Locations such as a journal, syslog or package-specific cron file are absent from the repository implementation. ToolAcre runs in a browser and does not query a host service manager. It would be misleading to name one path as the place a reader must find evidence.
Instead, ask the target scheduler for its own status and logs, then correlate timestamps with the generated preview. Matching a start record to an expected candidate isolates the failure to the action or output path. A missing start record points back toward installation, scheduler state or a dialect mismatch—not automatically a malformed expression.
Daemon logging locations are implementation-specific and omitted
A disciplined worked check starts with `30 2 * * *`. Confirm “At 02:30, every day” and note five upcoming dates in the deployment zone. Add observability to the command using the target’s documented mechanism, then test with harmless output. The schedule itself should not change during that experiment.
This method yields two independent artifacts: a calendar expectation and execution evidence. If output remains absent, compare the host clock and scheduler installation with the preview before editing fields. ToolAcre contributes a precise expected time, which is enough to make external logging investigations better bounded.
Worked boundary: preserve a validated schedule while adding observability elsewhere
Log rotation, retention, alert thresholds and delivery guarantees are separate systems. Nothing in `cron.js` opens files, rotates bytes or sends notifications. Even its warnings concern calendar combinations such as impossible dates and ORed day fields, not runtime failures.
Those omissions should be explicit in a runbook. A schedule that fires reliably can still fill a disk with output, while a silent command can fail without a useful alert. Use specialized controls for those risks and retain ToolAcre as the expression review tool rather than stretching it into an observability platform.
Rotation and alerting remain outside the generator
Cron syntax answers “which wall-clock minutes match?” Output configuration answers “where does the action’s evidence go?” ToolAcre solves the first question with parsing, descriptions, warnings and previews. It intentionally cannot answer the second from an isolated expression.
Build the five fields, verify the zone and calendar, then make output land somewhere through a separately tested deployment design. Reporting that boundary is not a limitation to hide; it prevents a valid expression from being mistaken for proof that a job ran, succeeded or left a retrievable record.