Skill · before the first production deploy

Observability Baseline

Most first launches go out with console.log and a plan to “check the logs if something happens”. This answers one question before they do: when this breaks in production, who finds out first — you, or a user?

Soumya Rauth · Creator & maintainer

npx skills add soumyaRauth/skills-hub --skill observability-baseline

The problem

launch → something breaks at night → a user emails in the morning

The gap is rarely a missing enterprise stack. Nothing was set up to tell a human, and nothing that was set up was ever tried. An alert that has never fired is a hope. A backup that has never been restored is a file.

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

Engages	An app is about to get its first production deploy with no monitoring; someone asks for logging, monitoring, alerting, error tracking, uptime checks, backups or a runbook, or “how will we know if it breaks?”; a postmortem shows nobody knew.
Stays quiet	Prototypes, libraries, a live incident being diagnosed, a log-line edit, dashboard tuning nobody asked about.
Depth	Shapes the work when asked. A few lines, never a gate, when a first production deploy is about to happen without it.
Works with	Engineering Investigator, Production Guard, Dependency Guard, ProofBuild

What it does

read what exists → seven items logs · health · errors · uptime · alert · backups · runbook
   → add what lives in the repo
   → prove each by making it fire
   → IN PLACE · ADDED · MISSING · NOT APPLICABLE

You:    We launch next week. How will we know if something breaks in production?

Agent:  OBSERVABILITY  bookshelf — first production deploy next week
        LOGS      MISSING  console.log of raw request bodies; no request id
        HEALTH    MISSING  no route; fly.toml has no checks
        ERRORS    MISSING  errors only printed
        UPTIME    MISSING  next: external HTTP check on /readyz
        ALERT     MISSING  next: one alert to the channel you read at night
        BACKUPS   MISSING  never restored
        RUNBOOK   MISSING  next: docs/runbook.md

        Today, if it goes down at night, a user tells you first.

Proven, not configured

ALERT   MISSING (never proven)   push to phone after repeated failed checks
        → stop staging (with your yes) → nothing arrives
        → phone notifications were off → fixed, re-run
ALERT   ADDED   received, and the recovery message too

Each item is marked done only with evidence that it fired: the test error in the tracker, the alert on your phone, a backup restored into a scratch database and a row read back. Production is never stopped to test.

Sized for one developer

One alert, one uptime check from outside the app’s own machine, one error tracker (hosted or self-hosted, decided through Dependency Guard). No metrics platform, tracing or dashboards unless you ask. Tool facts are checked against their official docs and dated; nothing secret or personal goes into a log, an event or the runbook.

Where it fits

During an incident it says nothing: Engineering Investigator diagnoses. Afterwards, it adds the one signal that was missing. Production Guard decides whether a change is safe to ship and may cite this baseline as evidence; this skill never states that verdict.