DEV Community: Abel Solutions

Your cron job fires on the wrong day

Abel Solutions — Tue, 28 Jul 2026 14:00:00 +0000

A team ports a job from a Quartz scheduler to a Unix crontab. The Quartz trigger ran Monday through Friday — day-of-week field 2-6, because Quartz numbers Sunday as 1, so Monday is 2 and Friday is 6. Someone copies that same numeric range, 2-6, straight into the new Unix crontab entry. Nobody touches the logic. Nobody gets an error. The cron daemon accepts the expression without complaint, because 2-6 is a perfectly valid day-of-week range in Unix cron too.

It just means something else there. Unix cron numbers Sunday as 0, so 2-6 is Tuesday through Saturday. The job now skips Monday and runs an extra day on Saturday — and because nothing crashes, nobody notices until someone asks why a report that's supposed to close out the work week is missing Monday's numbers and showing up on the weekend. That's the incident shape: not a crash, not a stack trace, just a schedule that's quietly wrong until a human cross-checks it against a calendar.

It's a symptom of a bigger problem: there is no single "cron standard." There are roughly eight dialects in common production use, and they agree on the broad strokes — five-ish fields, */,/-// operators — while disagreeing on the details that actually matter when you port an expression between systems.

Why: eight dialects, one shared ancestor

The lineage is short. POSIX/Unix cron (Version 7 Unix, 1970s) is the conservative baseline: five fields, no step syntax, no aliases. Paul Vixie's 1987 cron — what most Linux distributions actually ship — is the superset everyone means when they say "cron": it adds */n steps, named days and months, and @daily-style aliases. From there the tree splits two ways. Some systems fork Vixie's syntax and quietly change a rule or two: GitHub Actions and Kubernetes CronJobs both use 5-field, Vixie-style parsing, but they diverge from Vixie — and from each other — on aliases. GitHub Actions rejects @-aliases outright; Kubernetes keeps them and adds @every on top. Neither accepts 7 as an alias for Sunday, though, even though Vixie cron does. Other systems reinvent the field layout from scratch: Quartz (Java) adds a seconds field and flips day-of-week numbering; Spring's @Scheduled borrows Quartz's advanced tokens but keeps Unix-style day-of-week numbering; AWS EventBridge adds a year field and borrows Quartz's ?/L/W/# tokens along with its Sunday-is-1 numbering.

Here's the full comparison, built directly from CronPro's dialect definitions:

Dialect	Fields	Sunday =	Aliases (`@daily`, etc.)	DOM/DOW "don't care"
Unix / POSIX	5: min hour dom mon dow	`0` (no `7`)	None (strict POSIX)	No `?` token — ORs DOM and DOW when both are restricted
Vixie (Linux default)	5	`0` (`7` also accepted)	`@hourly` … `@reboot`	No `?` token — same OR rule
GitHub Actions	5	`0` (`7` not documented)	None — explicitly rejected	No `?` token — ORs DOM and DOW when both are restricted
Kubernetes CronJob	5	`0` (`7` rejected by the API server)	Yes (`@hourly` … `@every`)	No `?` token — OR-behavior not stated explicitly for K8s in source
AWS EventBridge	6 (adds year)	`1`	None	`?` required in exactly one of DOM/DOW
Quartz	6–7 (adds seconds, optional year)	`1`	None	`?` required in exactly one of DOM/DOW
Spring `@Scheduled`	6 (adds seconds)	`0` or `7`	Yes (since Spring 5.3)	`?` accepted (5.3+), but not required in either field — semantics differ from Quartz/EventBridge
Azure Functions (NCRONTAB)	6 (adds seconds)	`0` (no `7`)	None	No `?` token in this dialect — use `*`

Five traps that don't throw errors

1. Sunday's number changes between dialects. Unix, Vixie, and GitHub Actions number Sunday 0. Quartz and AWS EventBridge number it 1. That one-off shift is exactly what broke the crontab in the cold open: a Quartz 2-6 (Mon–Fri) becomes Unix 2-6 (Tue–Sat) if you copy the digits instead of re-deriving them. The fix is mechanical, not clever — re-map every numeric day value when you change dialects, or write the names (MON-FRI) instead of numbers, since day names mean the same weekday in every dialect that supports them.

2. Day-of-month and day-of-week are OR'd, not AND'd, when both are restricted. 0 0 1-7 * 1 looks like "the first Monday of the month." It isn't. When both fields carry a real restriction, Vixie-style cron fires the job if either matches — so that expression runs on every day 1 through 7 of the month, and on every Monday, whichever comes first. That's roughly 124 firings a year, not 12 — 84 from the date range plus 52 Mondays, minus the 12 days a year that are both (every month's first seven days contain exactly one Monday). This rule dates back to POSIX and holds in Vixie cron and the parsers derived from it — GitHub Actions documents the same behavior for schedule: triggers.

3. Kubernetes rejects 7 as an alias for Sunday. 0 0 * * 7 is valid in a Vixie crontab. Point the same string at a Kubernetes CronJob and the API server rejects it outright: end of range (7) above maximum (6). Same Vixie-style day-of-week field, but Kubernetes's parser drops the 0/7 dual-alias that Vixie cron allows. Use 0 0 * * 0 or 0 0 * * SUN instead — both work identically in both places.

4. In AWS EventBridge, the sixth field is year, not seconds. cron(0 12 * * ? *) runs daily at noon UTC — six fields, but the extra one past Unix's five is year, not sub-minute resolution. EventBridge has no seconds field at all. The other surprise in that same expression: the ? isn't decorative. EventBridge requires exactly one of day-of-month or day-of-week to be ?; cron(* * * * * *) is invalid because neither field opts out.

5. In Quartz, L in the day-of-week field means Saturday — literally the last day of the week — not "last occurrence in the month." It's an easy substitution to get backwards under a deadline: 0 0 0 ? * L fires every Saturday at midnight, full stop. For "last Friday of the month," the token you actually want is 6L (day 6, last occurrence), not L by itself.

The fix

For plain 5-field cron with no nth-weekday token, don't try to force the constraint into one expression. Schedule wide, then filter in the job itself: 0 0 1-7 * * fires on every one of the month's first seven days, and the job's first step exits unless it's actually the day you want — [ "$(date +%u)" = "1" ] || exit 0 for Monday. Two steps beat one clever, wrong one-liner, and the guard is portable to any shell the job already runs in.

Where the dialect gives you a native token, skip the workaround. Quartz and AWS EventBridge both support # for "nth weekday of the month" directly: 0 0 0 ? * 2#1 (Quartz) and cron(0 0 ? * 2#1 *) (EventBridge) both mean, literally, "the first Monday" — no guard clause, no wide schedule, no OR-semantics trap to fall into in the first place.

Where this leaves you

None of this is a defect in any one scheduler — each dialect is internally consistent, and the traps only show up at the seams, when an expression crosses from one system to another. We built a converter that handles the renumbering and de-stepping across all eight dialects and flags when a conversion is lossy — when the target dialect can't express what the source one did — instead of silently producing something that parses but means something different: cronpro.dev.

The NuGet gap Shai-Hulud exposed — and what we built to close part of it)

Abel Solutions — Fri, 24 Jul 2026 13:44:04 +0000

In September 2025, security researchers disclosed Shai-Hulud: a self-propagating worm that spread through the npm ecosystem by stealing maintainer credentials and using them to publish malicious versions of legitimate packages. CISA issued an alert within the week. By the time the dust settled, reporting put the number of poisoned packages above 500, including widely used libraries like @ctrl/tinycolor. The mechanism was the interesting part: compromised packages scanned the developer or CI environment for npm tokens, GitHub personal access tokens, and cloud credentials, then used whatever they found to publish more malicious versions — automated propagation, not a single actor manually re-uploading. A second wave, reported in late November 2025, showed the technique hadn't gone away.

None of that is .NET's problem, directly. But it raised an honest question for anyone shipping C# for a living: if the equivalent happened to a popular NuGet package tomorrow — a maintainer's account compromised, a malicious version pushed under a trusted name — what, exactly, would stop it from landing in your build the same day?

What NuGet actually has

To answer that fairly, it's worth listing what already exists, because it's more than "nothing."

Package signing. Authors can sign packages, and every package accepted onto nuget.org is automatically repository-signed. Verification is available via dotnet nuget verify, and starting with the .NET 8 SDK, signature verification is enabled by default using a certificate trust list Microsoft ships with the SDK. This establishes provenance and integrity — the package you're restoring is the bit-for-bit artifact that account uploaded, unmodified in transit.
Package ID prefix reservation. Organizations can reserve an ID prefix after a domain-verification process; once reserved, nuget.org rejects any new package under that prefix from a different account. This is a real defense against someone else publishing packages under your reserved namespace — an impersonation control, not an anti-typosquatting one (it doesn't stop a similarly-named-but-different prefix like Newtonsoft.Jso).
Trusted Publishing (OIDC). For CI-driven releases, nuget.org now supports exchanging a short-lived GitHub Actions OIDC token for a single-use, ~1-hour NuGet API key — removing the need for long-lived publish secrets sitting in CI, which is exactly the kind of credential Shai-Hulud went looking for on the npm side.

All of that is real, and none of it is nothing. It's also all aimed at the same layer: proving who published this and that it wasn't tampered with in transit. Signing answers "is this the artifact that account uploaded." It does not answer "should I trust code from a brand-new version of this package the moment it lands."

The gap: nothing gates on trust, and nothing gates on time

Two things are true at once, and neither is a NuGet-specific failing — npm has the equivalent gaps, just a different attack surface (install-time scripts by default, versus automatic build-time hooks for .NET). The ecosystems evolved different defenses on different timelines.

First: a signed, ID-verified package can still be malicious. Signing proves identity and integrity, not intent. If an attacker compromises the account that owns a reserved prefix, or if a malicious actor legitimately owns the identity they're publishing under, every defense above passes cleanly.

Second — and this is the part with a documented track record in .NET specifically — NuGet packages can carry executable logic that runs during build, not just at runtime. MSBuild supports inline tasks and .targets/.props files shipped inside a package's build/ folder. For PackageReference projects, those files get referenced through generated .nuget.g.targets/.props during restore, but the code inside them only executes when MSBuild subsequently evaluates and builds the project — restore alone doesn't run it. (Legacy install.ps1/init.ps1 scripts are a separate, older mechanism scoped to packages.config projects and the Visual Studio Package Manager; they don't apply to PackageReference projects at all, and they don't fire on dotnet restore either.) Researchers documented real campaigns exploiting the build-time mechanism — the "IAmReboot" wave in 2023 used malicious .targets files that fired, in ReversingLabs' own words, "every time package A is built." That's actually a sharper contrast with Shai-Hulud than a restore-time claim would be: npm's payload runs at install time, shipped as a postinstall hook that npm install executes automatically with no opt-out short of --ignore-scripts. NuGet's equivalent mechanism fires one step later in the pipeline — a dotnet build against a poisoned dependency can still execute attacker code before a single line of your own application code compiles, just not at the restore step itself.

And there's no cooldown anywhere in the pipeline. A version published ninety seconds ago restores exactly the same as one published two years ago. Nothing in the default toolchain treats "brand new" as a signal worth pausing on — and plenty of documented malicious-package campaigns, on NuGet and npm alike, get caught by security researchers days to weeks after publication, not before.

What NuGate does about it

We built NuGate as a dependency age gate. That's the whole scope, and we kept it that way deliberately: the build fails if any resolved package version — direct or transitive — was published less than a configurable number of days ago (seven, by default), unless it's explicitly allowlisted.

It ships as two pieces. NuGate.Tool is a dotnet CLI (nugate check) meant to run in CI between restore and build — gating before the next build ever runs, so a malicious .targets file in a freshly restored package never gets the chance to execute. That directly targets the build-time-execution gap above. NuGate.Build is an MSBuild task added as a single PackageReference in Directory.Build.props, gating every build in a repo including developers' own machines, hooked in after package assets resolve and before compilation starts. A thin GitHub Action wraps the CLI for workflow use.

The age comes from nuget.org's immutable catalog created timestamp — not the registration published field, which nuget.org resets to a sentinel value when a version is unlisted. A version that gets pulled after a compromise is discovered is flagged as a violation regardless of its age, closing that particular loophole. Failures are closed by default: if the nuget.org API is unreachable and age can't be determined, that counts as a violation rather than a silent pass. Config lives in a single nugate.json — minimum age, enforce vs. warn mode, an allowlist with optional expiry dates so exceptions don't quietly become permanent, and prefix exemptions for internal packages that never touch nuget.org.

Equally important is what it doesn't do. NuGate does not detect malware, does not scan package contents, and does not prevent attacks. A compromised package that's thirty days old passes the gate exactly the same as any other dependency, by design. A cooldown shrinks the window in which a freshly poisoned version can reach a build — it does not close that window, and it says nothing about what's inside the package. Anyone evaluating it should read it as a narrow, boring control, not a security product.

Where to find it

We've released NuGate as open source, Apache-2.0, under the AbelSolutions-io GitHub organization. It installs from NuGet — NuGate.Tool for CI, NuGate.Build for the MSBuild integration. Issues and questions are welcome on the repo. There's a small landing page with a longer explanation of the cooldown model at nugate.dev if you want more than this post covers.

No pricing, because there isn't any.