English

Developer tools · Crontab generator

@reboot, @daily, @hourly: where cron's nickname schedules came from

· Background

cron aliases scheduling

Seven named schedule aliases expanding into five fields beside a blocked reboot symbol
Original ToolAcre vector illustration

The @ shorthands are readable, popular and not universal. This post explains what each expands to, where they came from, the special case of @reboot, and when to write the five fields instead.

@reboot is refused because the tool previews calendar times, not startup events

`@reboot` looks like the other at-sign forms but has no five-field calendar expansion in ToolAcre. The parser refuses it with an explicit reason: there is no schedule to preview. A startup event depends on a machine or service lifecycle that this browser route neither observes nor controls.

This distinction keeps the next-run list honest. Calendar aliases can become concrete fields and dates. A reboot alias cannot produce five future wall-clock candidates from the current instant without inventing future restarts. Refusal is therefore more accurate than an empty or fabricated preview.

The nicknames and their expansions — @hourly, @daily and @midnight, @weekly, @monthly, @yearly and @annually as five-field equivalents

The supported table is exact. `@hourly` becomes `0 * * * *`; `@daily` and `@midnight` become `0 0 * * *`; `@weekly` becomes `0 0 * * 0`; `@monthly` becomes `0 0 1 * *`; and `@yearly` plus `@annually` become `0 0 1 1 *`.

The UI resolves an accepted alias before copying values into the five individual boxes. Parsing returns the normalized five-field expression, descriptions use that parsed form and tests iterate through every alias. The expansion is therefore inspectable rather than hidden shorthand.

No daemon-start or system-boot behavior is modeled

No code in this path receives operating-system startup events. There is no daemon process, boot identifier or service dependency graph. The workbook’s statements about when `@reboot` runs cannot be established from a parser that deliberately rejects the token.

If a target supports a startup nickname, consult that target’s lifecycle definition and test it safely. Do not use ToolAcre’s error as proof that the feature is universally invalid, and do not use another implementation’s support as proof that this route should preview it.

Alias origins and cross-implementation spread require external historical sources

The workbook attributed aliases to a historical implementation and described their spread. The repository contains no primary history source for that claim. What it proves is present-tense behavior: seven keys in `ALIASES`, case-insensitive lookup and rejection of unknown shorthands.

That is enough for practical documentation. Readers can see exactly which forms work here and what they expand to. Provenance can be added later with an archival source; it should not be inferred from a constant name or the popularity of similar syntax elsewhere.

Worked example: replacing @daily with 0 0 * * * — and why the explicit form also lets you move the time off midnight

Replacing `@daily` with `0 0 * * *` exposes the time fields. Changing the hour from 0 to 4 produces `0 4 * * *`, which the tool describes as 04:00 every day. The explicit form is better when midnight is not the intended wall time.

The field boxes make that adjustment straightforward and the selected time zone controls preview instants. The copied expression contains no alias after expansion in the parser result, but the original text may remain in the whole-expression box until a field is changed. Review the actual copied value before deployment.

Boot-time ordering and dependencies are outside the generator

Startup work often depends on filesystems, networks, credentials or other services. ToolAcre has no dependency model and cannot assess readiness, delays or restart behavior. Even if it accepted `@reboot`, expression validation would not solve those operational questions.

Treat boot-time execution as a lifecycle design rather than a calendar shortcut. Document prerequisites and failure handling in the target environment. The generator remains appropriate for recurring five-field schedules whose next wall-clock times can actually be computed.

Service-manager alternatives are not evaluated here

The workbook pointed toward modern service units, but this repository does not build or compare them. No unit syntax, dependency directive or startup test is among the sources. The article therefore avoids recommending a replacement based solely on an unsupported nickname.

Choose a lifecycle mechanism from target documentation and operational requirements. ToolAcre’s contribution is the negative boundary: `@reboot` is outside its previewable domain, while ordinary calendar aliases have transparent five-field equivalents.

Takeaway: nicknames are sugar for fixed expressions — and the generator lets you build the explicit version and read it back

Aliases are concise labels for fixed expressions in this implementation. Expand them whenever review or customization benefits from seeing the positions. `@daily` is not magic; it is midnight in all unrestricted calendar fields under the selected preview zone.

Use the supported list, inspect the expansion and move away from midnight when appropriate. For startup events, stop and select a target-specific mechanism instead of forcing an unpreviewable lifecycle trigger into a calendar generator. That boundary is deliberate and tested.