First Friday is an intersection, not two alternative reasons to run
A schedule can look like a plain-language requirement while selecting a much larger set of dates. The mistake is easier to find by listing the selected dates than by repeatedly reading the expression and assuming its fields combine in the intended way.
The case below is fictional. It uses the documented behaviour of Cronie 1.7.2, as packaged in the inspected Debian 1.7.2-5 source, and an isolated date-selection model. No scheduler is installed, no job is run and no message is sent as part of the example.
Write the owner's rule independently of the expression
The approved task R-61 prepares a monthly internal review at 09:00 on the first Friday of each month in Europe/Amsterdam. This is the organisation's chosen rule. It is not a claim about a Dutch statutory deadline, a national workweek or anyone's availability to attend.
For November 2026, the intended date is Friday 6 November. For December, it is Friday 4 December. An independent task W-62 is intentionally weekly and should remain eligible every Friday.
The faulty R-61 expression is 0 9 1-7 * 5. Its author assumed that a date must fall within the first seven days and be a Friday. The installed scheduler's field semantics need to be checked rather than inferred from that intention.
Read the scheduler's documented combination rule
The Cronie 1.7.2-5 crontab manual source explains that, when both day-of-month and day-of-week fields are restricted, a match in either is sufficient. The packaged manual also documents the CRON_TZ setting for the table's time zone.
In this fixture, the faulty expression therefore selects every date from the first through the seventh, plus later Fridays. November 1 is selected because it is within the first seven days, although it is Sunday. November 13 is selected because it is Friday, although it is not the first Friday.
The defect is in combining calendar conditions. Changing the hour or applying a different offset would not repair it. Nor would changing the owner's monthly rule merely to make it agree with the existing expression.
Separate the Friday trigger from the monthly gate
The proposed correction uses the documented weekly Friday expression 0 9 * * 5, followed by an explicit gate that allows R-61 only when the local calendar day is between 1 and 7 inclusive. Both the schedule and the gate use the agreed Europe/Amsterdam date interpretation.
The gate checks the intended date and refuses an unknown or invalid date basis. It does not quietly use the machine's unrelated local zone. The review also checks that the task cannot bypass this condition through its normal supported entry point.
This is a description of the bounded design, not a command to paste into a production crontab. The actual runner, permissions, environment and failure handling still require their own authorised implementation and review.
Compare complete date membership
The isolated model enumerates every date in November and December 2026. Under the faulty predicate, November selects days 1–7 and 13, 20 and 27. December selects days 1–7 and 11, 18 and 25. The overlap on the first Friday is one selected date, not a reason to count that day twice.
With the corrected Friday trigger and monthly gate, the accepted set is exactly 6 November and 4 December. The model explicitly refuses 1 November and 13 November for R-61. It retains the approved 09:00 local time in the candidate records.
W-62 remains weekly. Its November dates are 6, 13, 20 and 27, and its December dates are 4, 11, 18 and 25. The monthly gate is not applied globally to every Friday job. This independent control establishes that the repair is limited to the task whose rule requires it.
Record the result without claiming execution
The fictional owner accepts the corrected date-selection design after comparing the complete sets. The evidence establishes which dates the model selects under the documented rule. It does not establish that a daemon executed a job, that a provider delivered a message or that a person attended a review.
Operational checks would still need the actual scheduler version, environment, permissions and observations under an authorised plan. Failure to start, delayed execution and other runtime concerns are separate from this calendar-membership result.
The handover keeps the owner's wording, the original expression, the precise scheduler reference, the corrected gate and both monthly and weekly expected sets. It also names who may change the business rule.
Use the software-repair service to investigate a schedule that produces unexpected work. Bring the actual expression, scheduler identity and dated expectation to project planning; a label such as “monthly” is not enough to establish what the system will select.