Execution-signal-based monitoring for cron jobs, workers, and scheduled tasks.
Pakyas exists because jobs are not servers. They are expected to run at specific times and must prove that they did.
A job is only On Schedule after it emits a successful execution signal. Silence is never treated as healthy.
This allows Pakyas to verify:
The Signal Model
No polling. No guessing. No false green states.
Pakyas models how jobs actually behave, not how servers work.
A valid execution signal arrived on time
The job ran, but outside its expected window
No execution signal was received
Execution has started but not completed
Execution exceeded expected duration
The job is intentionally disabled
Late is not failed. | Missing is not healthy.
Pakyas alerts only when a job's state meaningfully changes. Not when a ping repeats. Not when nothing actionable happened.
Rare
Only on state transitions
Explainable
Clear reason for every alert
Trusted
Alerts that mean action
Each job keeps a clear execution timeline:
History exists to explain behavior, not to look green.
Jobs emit signals directly from where they run today. No agents. No server assumptions.
Cron Jobs
Background Jobs
Scheduled Tasks
Long-Running Workers
Jobs live in code. Monitoring should too.
Pakyas treats the CLI as a first-class interface so execution signals stay close to the job itself. The UI exists to explain state, not replace intent.
Explore the CLI Guide$ pakyas monitor nightly-backup -- ./backup.sh
[pakyas] Start signal sent
Backing up database...
Uploading to S3...
[pakyas] Finish signal sent (exit: 0, 12.4s)Traditional monitoring answers the wrong question.
Pakyas answers the only one that matters:
Did the job actually run, when it was supposed to, and complete as expected?
Monitoring should reduce stress, not create it.
Silence is never mistaken for success
Alerts always mean action
Engineers can trust what they see
Install the CLI. Emit execution signals. Let your jobs tell the truth.