scheduled-jobs

Standardizes authoring, installing, and instrumenting systemd timers and scheduled jobs on managed hosts.

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/leonardoacosta/skills --skill scheduled-jobs-leonardoacosta
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: scheduled-jobs
Source: https://github.com/leonardoacosta/skills/tree/main/leo-core/skills/scheduled-jobs
Command: npx skills add https://github.com/leonardoacosta/skills --skill scheduled-jobs-leonardoacosta

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Scheduled jobs on managed hosts often fail silently: symlinked systemd units vanish during git checkouts, unprefixed job names make ownership unclear, and jobs that bypass run recording become invisible to health checks. This Skill enforces conventions that keep every scheduled unit owned, installed safely, and observable. ## Core Features & Use Cases - Directory-and-manifest model: Keeps every schedule in one directory with a manifest listing job name, schedule, command, timeout, and owner alongside the systemd unit files. - Naming and install conventions: Enforces <owner>-<job> prefixes and regular-file installs instead of symlinks, preventing the "Unit to trigger vanished" failure class. - Structured run records: Requires every run to append a JSONL record with timestamps, exit code, duration, and timeout status so downstream health checks can verify execution. - Use Case: When adding a nightly cleanup timer to a Linux host, use this Skill to name it correctly, install it as a regular file with systemctl --user enable --now, and wire run-record emission in the same change. ## Quick Start Use the scheduled-jobs skill to add a new systemd user timer for my nightly backup script with proper naming, installation, and run logging.

Frequently Asked Questions about scheduled-jobs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I install a systemd user timer safely?

Install the unit as a regular file by copying it into ~/.config/systemd/user/ with install -m 644, then run systemctl --user daemon-reload and systemctl --user enable --now. Never symlink a unit into a live git checkout, since checkouts can unlink the target and permanently fail the timer.

How should I name scheduled jobs and systemd timers?

Use an <owner>-<job> prefix convention such as mesh-heartbeat or claude-ratchet so namespace ownership is recoverable. When modifying any existing job whose name lacks a prefix, rename it as part of that same change rather than deferring cleanup.

Why did my systemd timer fail with 'Unit to trigger vanished'?

This happens when the unit is a symlink into a live git checkout and a checkout, rebase, or branch switch momentarily unlinks the target. Systemd fails the timer and does not recover on daemon-reload or reboot; reinstall the unit as a regular copied file.

What fields should a scheduled job run log include?

Each run should append a structured record with ts_start, ts_end, job name, trigger type, host, exit code, duration in seconds, and a timed_out boolean. Manual runs must use the same entry point as scheduled runs so health checks can see every execution.

Does this convention support cron or launchd instead of systemd?

systemd user timers are the standard on Linux hosts, and launchd is the documented macOS equivalent. cron, anacron, and at are treated as non-standard, while GitHub Actions and Vercel crons are documented separately and out of scope for unit-file conventions.