A free terminal tool finds broken cron, launchd, and systemd jobs and gives you the fix command

An automation that never starts can leave you with the same result as an automation that crashed: nothing. turnus tries to put the difference on screen, along with the file or setting that explains it. Scheduled work gets a schedule checkup, which is a more useful appointment than another silent failure.

The project’s README describes a terminal interface for cron jobs, launchd agents and systemd timers. It checks missing executables, absent log directories, unloaded jobs and schedules that cannot match a real date. The point is to turn an apparently valid definition into a concrete explanation of why it will not do the work.

One example is launchd exit code 78. The project says that code can cover both a missing program and a missing log folder. Those call for different repairs, despite sharing a number. Checking the paths is more helpful than treating the exit status as a complete diagnosis and searching the same vague error until lunchtime.

The tool’s default role is inspection. The README says it “never changes” jobs and does not run in the background. In the interface, you can open logs, edit a definition through an explicit action or copy the proposed fix. A diagnostic display does not have to become an unattended repair service just because it knows where the problem might be.

There are important differences between schedulers. The check table does not promise cron run history; failure and crash checks apply to launchd and systemd where the relevant information exists. On cron, a sound definition and an executable file still cannot prove that yesterday’s task ran. A missing observation stays missing (refreshing honesty).

For shell commands, the project checks details that can hide in otherwise ordinary text. An unescaped percent sign means something special to cron. Some run-parts implementations skip scripts because of their names. A task scheduled during a daylight-saving transition can miss its expected time. Each is a small rule with a surprisingly large capacity to spoil a simple plan.

The command-line mode makes the inspection reusable. The documented ls –check command returns 1 when a job is failing and 2 when the inspection itself encounters an error; warnings do not change the result. That distinction gives a caller a chance to separate a broken task from a broken attempt to look at tasks.

For an operator inheriting a machine, the useful first pass is therefore an inventory with reasons attached. It does not establish that the business outcome happened, and it cannot reconstruct history the scheduler never saved. It can remove the much smaller mystery of a program that was never executable or a log folder that prevented launch in the first place.

The job had one job.