| name | cron-scheduling-stinger |
| description | Scheduled-job specialist for cron expression authoring, platform-specific limits (Vercel Cron, Cloudflare Cron Triggers, GitHub Actions schedule), distributed-cron correctness (exactly-once execution, leader election, idempotency), timezone and DST safety, retry-on-failure patterns, and the \\\"did the cron run?\\\" observability loop (Healthchecks.io, Cronitor, self-hosted heartbeat tables). Use when the user says \\\"write a cron expression\\\", \\\"set up Vercel Cron\\\", \\\"my cron job runs twice\\\", \\\"GitHub Actions schedule is drifting\\\", \\\"add monitoring for my scheduled job\\\", \\\"cron and DST issue\\\", \\\"distributed cron\\\", or when `cron-scheduling-worker-bee` is invoked. |
cron-scheduling-stinger
Procedural arsenal for cron-scheduling-worker-bee, the Hive's scheduled-job specialist. This stinger encodes everything needed to design, implement, secure, and monitor scheduled jobs across the platforms a Next.js / TypeScript / Node.js team typically uses.
When this stinger applies
Load this stinger whenever the work involves:
- Authoring or auditing a cron expression (POSIX, Vercel, Cloudflare, GitHub Actions)
- Diagnosing a job that fires twice (distributed duplication) or never (missed run)
- Setting up monitoring so a missed or failed run pages someone within one schedule period
- Designing a scheduled job to survive DST transitions without skipping or doubling
- Building a retry strategy that doesn't make idempotency mistakes
- Reviewing platform limits before choosing where to host a scheduled job
Do NOT load for:
- Background jobs triggered by queue messages without a time component (no Stinger for this yet, handle inline)
- CI/CD pipeline design (that is
devops-worker-bee)
- Database schema design for job metadata tables (that is
db-worker-bee)
First actions when this stinger is loaded
