Xpersona
C

cron-sentinel

CLAWHUB · Unverified

Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'add retries and a dead-man's switch to my cron,' or 'is my nightly task still actually running.' It wraps a scheduled command so each run is recorded (exit code, duration, redacted output tail) with optional retries and a timeout, then a watchdog flags both crashed jobs and overdue jobs that silently never ran. Do NOT trigger on plain scheduling requests with no monitoring need ('remind me at 5,' 'run this once tomorrow'), or on general cron-syntax questions ('what does * * * * * mean') - only when reliability or silent-failure detection is the actual ask. Runs a local, standard-library-only Python tool that executes the user's own command directly (no shell), keeps an owner-only state file under ~/.cron-sentinel/, and prints crontab lines for the user to add themselves. It never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges.

62
Rank
84
Safety
988
Downloads

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 988 downloads reported by the source. Last updated 10/11/2026.

Avoid when

  • Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Install and run

Setup complexity: low.

clawhub skill install s17f63svb641q2stekk1cmcdn183k4rq:cron-sentinel
  1. Install using `clawhub skill install s17f63svb641q2stekk1cmcdn183k4rq:cron-sentinel` in an isolated environment before connecting it to live workloads.
  2. No published capability contract is available yet, so validate auth and request/response behavior manually.
  3. Review the upstream CLAWHUB listing at https://clawhub.ai/chris/cron-sentinel before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

49,762 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: cron-sentinel
version: 1.2.0
description: "Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'add retries and a dead-man's switch to my cron,' or 'is my nightly task still actually running.' It wraps a scheduled command so each run is recorded (exit code, duration, redacted output tail) with optional retries and a timeout, then a watchdog flags both crashed jobs and overdue jobs that silently never ran. Do NOT trigger on plain scheduling requests with no monitoring need ('remind me at 5,' 'run this once tomorrow'), or on general cron-syntax questions ('what does * * * * * mean') - only when reliability or silent-failure detection is the actual ask. Runs a local, standard-library-only Python tool that executes the user's own command directly (no shell), keeps an owner-only state file under ~/.cron-sentinel/, and prints crontab lines for the user to add themselves. It never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges."
metadata:
  openclaw:
    emoji: 🛡️
    requires:
      bins: [python3]
      config: ["~/.cron-sentinel/state.json"]
    envVars:
      - name: CRON_SENTINEL_STATE
        required: false
        description: "Optional path override for the state file. The only environment variable the tool reads."
---

# Cron Sentinel

Everyone monitors the job that crashes. Almost nobody catches the job that just... stops. The machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded - the task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel is a dead-man's switch for your scheduled tasks: it records every run and alerts you both when a job fails loudly and when it goes silent.

Four jobs:

1. **wrap** - run your scheduled command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.
2. **check** - the watchdog. Reports any job that crashed (non-zero exit) or is overdue (expected to have run by now but hasn't). Exits non-zero if anything is wrong, so it can drive an alert.
3. **status** - a quick table of every tracked job: last run, health, when it's next expected.
4. **crontab** - print a ready-to-paste crontab line that wraps a command, plus a watchdog line.

## Permissions & data

This skill is not informational - it runs a local tool (`cron_sentinel.py`) that touches the system. Be transparent with the user about exactly what it does, and never run it on a command they didn't ask you to wrap. Its full reach:

- **Command execution.** `wrap` runs the command placed after `--` as a direct sub

README.md

# Cron Sentinel 🛡️

A dead-man's switch for your scheduled tasks. Bulletproof scheduling that alerts you when a job **silently** fails.

Everyone monitors the job that crashes. Almost nobody catches the job that just... stops — the machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded. The task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel catches both the loud failures and the silent ones.

## What it does

- **wrap** — run your command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.
- **check** — the watchdog. Flags any job that crashed *or* is overdue (should have run by now but didn't). Exits non-zero so it can drive an alert.
- **status** — a quick table of every tracked job: last run, health, next expected.
- **crontab** — prints a ready-to-paste wrapped crontab line plus a watchdog line.

## Quick start

```bash
# What cron actually runs:
python cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh

# The watchdog (its own short schedule):
python cron_sentinel.py check       # exits 1 if anything failed or went silent
python cron_sentinel.py status

# Generate the crontab lines:
python cron_sentinel.py crontab --name backup --schedule "0 3 * * *" --expect-every 1d -- /path/backup.sh
```

The command always goes after `--`. `--expect-every` (`30m`, `12h`, `1d`, `1w`) is what makes silent-failure detection possible — it's how Sentinel knows a job *should* have run. State lives in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC, so it's correct across timezones and DST.

## The whole idea in two lines

1. The **wrapped job** runs your real task on its normal schedule.
2. The **watchdog** runs `check` every few minutes and pings you only when something's wrong.

A `💥 failed` means it ran and errored (show the output tail). A `🔇 overdue` means it never ran — the problem is upstream, not the command. That distinction alone saves hours of debugging.

## Safety and scope

- Runs only the command you give it, directly, never through a shell
- Never edits your crontab or creates scheduled tasks: `crontab` just prints lines for you to add
- No network access and no dependencies; runs as your normal user
- State is kept in one owner-only file (`~/.cron-sentinel/state.json`)
- Secret-looking values in captured output are masked before saving; use `--no-output-tail` to save no output at all

## Requirements

- Python 3.8+ (standard library only). No API key, no external services.

_meta.json

{
  "ownerId": "kn77r9qjvh6fy4aja2km8bzgvd83khv9",
  "slug": "cron-sentinel",
  "version": "1.2.0",
  "publishedAt": 1790618992780
}

CHANGELOG.md

# Changelog

All notable changes to Cron Sentinel are documented here. Format follows [Keep a Changelog](https://keepachangelog.com/); this project adheres to semantic versioning.

## [1.2.0] - 2026-09-28

Fixes from ClawHub's security audit. Existing commands and state files keep working.

### Security
- **State file is now owner-only.** The state folder is created with 0700 and `state.json` is written with 0600.
- **Secrets are redacted before saving.** Captured output is scanned for common credential patterns (password/token/API-key assignments, bearer and basic auth headers, AWS, GitHub, Slack and `sk-` style keys, private-key blocks, credentials in URLs) and masked before it's written to the state file.
- **New `--no-output-tail` flag** for `wrap` stores no command output at all.
- **`crontab` output is validated and quoted.** `--name` must be a simple identifier, `--schedule` must be five cron fields or a macro like `@daily`, `--expect-every` must parse as a duration, the Python and script paths are quoted, and `%` is escaped so the printed line can't be broken or injected into.
- `wrap` now passes `shell=False` explicitly and documents that commands are never run through a shell.

### Changed
- Replaced the frontmatter `permissions` block (not part of ClawHub's schema, so it wasn't being read) with `metadata.openclaw.requires` and `envVars` declarations.
- SKILL.md and the description now state plainly that Sentinel never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges, and that the agent must not create scheduled tasks without the user's explicit confirmation.
- Corrected the description, which previously said commands run "via the shell."
- `crontab` output now opens with a note that Sentinel doesn't install anything.

### Added
- `.clawhubignore` so development-only files (`evals/`) stay in the repository but aren't published to ClawHub.

## [1.1.0] - 2026-05-24

Security-review fixes. No behavior change to the tool itself.

### Added
- Explicit `permissions` block in the SKILL.md frontmatter (shell execution, state-file read/write under `~/.cron-sentinel/`, the `CRON_SENTINEL_STATE` env var, and no network) so the skill's real capabilities are visible to the permission model and to reviewers instead of being implicit in the code.
- "Permissions & data" section documenting exactly what the skill touches, plus a secrets warning that `wrap` stores the last ~2000 chars of a job's output in `state.json` in plaintext (with mitigations).
- "When NOT to use" guidance to keep the skill from activating on plain scheduling requests, cron-syntax questions, and one-off reminders.

### Changed
- Tightened the description and "When to use this" triggers to scope activation to reliability / silent-failure-detection intent rather than every mention of scheduling.

## [1.0.0] - 2026-05-23

Initial release.

### Added
- `wrap` command: runs a scheduled command and records each run (start, end, exit code, durati

skill-card.md

## Description:

Monitors recurring jobs for failures and missed runs, with optional retries and guidance for setting up alerts.

This skill is ready for commercial/non-commercial use.

## Publisher:

[chris](https://clawhub.ai/user/chris)

### License/Terms of Use:

MIT-0

## Use Case:

Developers and operators use this skill to detect failed or overdue scheduled jobs and set up a watchdog that can trigger their chosen alerting channel.

### Deployment Geography for Use:

Global

## Known Risks and Mitigations:

Risk: Generated crontab lines may schedule commands or alerts differently than intended.

Mitigation: Review generated lines before adding them to the scheduler.

Risk: Captured job output may contain credentials or other sensitive data despite best-effort redaction.

Mitigation: Use --no-output-tail for jobs that may print sensitive information.

## Reference(s):

- [Cron Sentinel on ClawHub](https://clawhub.ai/chris/skills/cron-sentinel)

## Skill Output:

**Output Type(s):** [Shell commands, Configuration instructions, Guidance]

**Output Format:** [Markdown with shell snippets and human-readable job status]

**Output Parameters:** [1D]

**Other Properties Related to Output:** [Generated crontab entries require user review and installation; watchdog checks can exit non-zero to signal unhealthy jobs.]

## Skill Version(s):

1.2.0 (source: frontmatter, changelog, ClawHub release)

## Ethical Considerations:

Users should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.

Sponsored

Ads related to cron-sentinel and adjacent AI workflows.