A Scheduled Job That Ran Without the VPN Looks Fine

The job status says success, the log shows a completed run, and the data is stale or absent. That combination usually means the scheduled task started without the path it needed, and something downstream swallowed the failure. A schedule that fires on time says nothing about whether the network was ready. The gap between those two facts is where this failure lives.

Admission belongs to the run, not to the existence of a cron file.

A Green Run Is Not a Completed Job

A scheduler notes that a process started and later exited; it has no idea whether that process reached the resource it exists for. A script that treats a failed connection as an empty result, or catches an error and exits zero, will look healthy forever. The symptom is not a red status; it is a plausible status attached to missing work.

Name what the run actually needs before deciding how to check it. A backup may need private DNS and an authenticated endpoint, not merely a tunnel process.

Check the Connection, Not the Interface Name

An interface called tun0 can exist without the session that matters, and another connection may own that name. Check the specific object the job depends on: one profile identity, one service instance, or a small approved operation against the resource. Keep the check bounded in time, and keep credentials out of process arguments and diagnostic logs.

Define the disconnected outcome as well. An ordinary skip, a retry inside a short window and an operator-visible missed deadline are three different answers, and a recurring schedule does not choose between them.

Skips and Failures Are Different Outcomes

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

On a systemd deployment, ExecCondition= runs that checker before the workload. Its exit behaviour is specific: zero continues, codes from one to 254 skip the remaining start commands without marking the unit failed, and 255 or abnormal termination fails it. That gives three distinct signals, useful only if the checker's contract maps to them deliberately. Settings that redefine success can change the picture, so document the mapping.

Recording skips is what makes the design honest. A skipped run that appears nowhere is indistinguishable from a run that succeeded, and treating every checker error as a quiet skip conceals a broken deployment indefinitely.

Guard the Whole Run, Not Just the Start

A readiness check observes the world before launch; it does not police every socket afterwards. When a direct path is never acceptable for this task, attach an approved egress policy that is enforced continuously, covering DNS, IPv6 and the tunnel's own transport. Toggling the host's global IPv6 state is not a substitute for a scoped policy on the task.

Decide whether a new event may overlap a still-running job, keep that rule with the workload owner, and make retry safe for the data operation. Stopping a task on disconnect limits work without guaranteeing anything about fallback traffic.

Accept the workflow on three cases: ready path, unavailable path, and mid-run loss. Anything less tests the schedule, not the job.