Honeybadger

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the three-in-one monitor that replaces Honeybadger: errors, uptime and cron.

The insight worth copying is that these are the same product — something happened, or something failed to happen — and they should share one alert path.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A worker process for the checks
- Caddy in front

THE SHARED CORE
- incidents: id, kind, subject_id, opened_at, closed_at, severity, summary — errors, uptime and cron all open one
- notifications: id, incident_id, channel, sent_at, status
- **One alert path for all three**: routing, quiet hours, escalation and deduplication written once. That is the argument for building them together rather than buying three

ERRORS
- Ingest, fingerprint from your own frames with variable parts normalised, group, count
- Rate limit per group; a hot loop must cost a counter and not a disk
- Scrub secrets before storing, deny by default

UPTIME
- HTTP checks on an interval with a timeout, from a machine that is not the one being watched — **a check running on the same server tells you nothing when that server dies**, and that is the whole point of the category
- Confirm a failure from a second location before opening an incident. One network blip should not wake anybody
- Record every check, alert on the state change
- Certificate expiry as its own check, thirty days ahead. It is the cheapest outage to prevent and the most embarrassing to have

CRON, WHICH IS THE ONE NOBODY BUILDS
- A job registers an expected schedule and pings a URL at start and finish
- **Missing the ping is the alert.** A job that silently stopped running is invisible to every other kind of monitoring, and it is usually the backup
- Record the duration, and alert on a run that takes far longer than its own history
- A grace period per job, because a nightly job at 03:00 sometimes starts at 03:04

ALERTING WITHOUT BEING HATED
- Deduplicate: one open incident per subject, updated rather than repeated
- Quiet hours with a severity that overrides them
- Escalate if unacknowledged, and stop when acknowledged
- **Alert on recovery too.** An incident with no closing message means somebody checks manually at midnight

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SMTP_URL, ENCRYPTION_KEY, PUSH_KEYS
- Migrations on boot; occurrences and check rows pruned on a stated retention while incidents are kept forever
- Health endpoint reporting queue depth and the age of the last completed check round

WHAT MATTERS MOST
The cron dead-man switch and the external vantage point. Those are the two failures your own application can never report on its own.