Agent install

Install with your coding agent

Your coding agent scans your project and machine. StillRunning gives it the API and a playbook to create, reconcile, wire, and verify monitors. Drop an API key in your environment, paste the prompt below into Claude Code or Codex, and your agent discovers your cron jobs, scheduled tasks, and agent scripts, then sets up monitoring for each, with your confirmation before it touches anything.

StillRunning does not reach into your machine. Discovery is done by your agent, with its own file and shell tools. We supply the safe primitives: a key-authed API, an idempotent reconcile, and connectivity tests that can never fake a healthy run.

1. Create an installer key

Go to stillrunning.ai/app/settings and create an API key. Put it in your environment:

STILLRUNNING_API_KEY=sr_live_xxxxxxxxxxxxxxxxxxxxxxxx

An installer key can create, read, and scan monitors and send connectivity test pings. It deliberately cannot reveal the ping URL of a monitor it did not just create, and cannot rotate tokens, so a leaked installer key can't harvest your existing ping URLs.

2. Paste this prompt into your agent

Works with Claude Code, Codex, or any agent that can run shell commands and curl. It forces a confirmation step before any file is edited.

You are setting up StillRunning monitoring for my scheduled jobs.
My StillRunning API key is in the environment as STILLRUNNING_API_KEY.
Base URL: https://stillrunning.ai/api/v1. Auth header: "Authorization: Bearer $STILLRUNNING_API_KEY".

Follow these steps IN ORDER. Do not skip the confirmation step.

1. INSPECT: use your own tools to find my scheduled work, do not guess. Check:
   - crontab -l
   - ~/Library/LaunchAgents and /Library/LaunchAgents (launchd, macOS)
   - systemctl list-timers (systemd, Linux)
   - .github/workflows/*.yml for "schedule:" cron triggers
   - vercel.json "crons"
   - any custom watchdog / agent scripts in this project
2. LIST every job you found: name, the command that runs it, and its schedule.
3. DRY-RUN: POST /api/v1/install/reconcile with dryRun:true and a "monitors" array where each item
   has name, schedule (cron or "6h"/"30m" or seconds), sourceType (crontab/launchd/systemd/
   github-actions/vercel-cron/agent-script), sourcePath, and command. Show me the diff it returns
   (created / updated / unchanged / rejected / missingFromLatestScan). Surface any rejected items.
4. SHOW ME the exact files and commands you will edit to add the pings.
5. STOP and ask me to confirm. Do NOT edit my crontab, launchd, systemd, GitHub Actions, Vercel
   config, scripts, or wrappers until I say yes.
6. APPLY: after I confirm, re-send the same monitors with dryRun:false. Capture the pingUrl
   returned for each NEW monitor, that is the only time the URL is returned. Treat it like a secret.
7. WIRE each job with the correct fail-path so a monitoring outage can never break the job:
   ping the URL on success, and curl "URL?event=fail" on failure (trap ERR / || in shell,
   if: failure() in Actions, try/finally in code). Never let a ping failure change the job's exit.
8. TEST each monitor: POST /api/v1/workflows/<id>/test-ping. It will report
   "endpoint verified, waiting for first real run". That is NOT healthy yet, and that is correct.
9. REPORT back: each monitor wired + endpoint-verified, and that it goes healthy on its first real
   run and alerts if it ever stops.

3. What the agent does

Inspect → list jobs → dry-run reconcile → show proposed changes → ask you to confirm → apply → wire with a safe fail-path → test the endpoint → report. The heavy lifting is one endpoint, POST /api/v1/install/reconcile, run first with dryRun:true to preview, then dryRun:false to apply:

curl -s -X POST https://stillrunning.ai/api/v1/install/reconcile \
  -H "Authorization: Bearer $STILLRUNNING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "crontab",
    "dryRun": true,
    "monitors": [
      { "name": "Nightly DB backup", "schedule": "0 3 * * *",
        "sourceType": "crontab", "sourcePath": "/etc/crontab",
        "command": "/usr/local/bin/backup.sh" }
    ]
  }'

The response splits the scan into created, updated, unchanged, rejected, and missingFromLatestScan. Re-run with dryRun:false to apply; each brand-new monitor comes back with a pingUrl in created[]. After wiring, verify the endpoint by id:

curl -s -X POST https://stillrunning.ai/api/v1/workflows/<id>/test-ping \
  -H "Authorization: Bearer $STILLRUNNING_API_KEY"
# -> { "verificationState": "endpoint_tested",
#      "message": "Endpoint verified. Waiting for first real run." }

The two-axis state model

A monitor has an install state separate from its health, so "I tested the wiring" can never masquerade as "the job is running fine":

created , the monitor exists, nothing has pinged it yet. endpoint_tested , a connectivity test reached it (the endpoint is verified), but the real job has not run yet, so it is not healthy. real_run_seen , a real production ping landed; from here normal health applies (missed runs, duration, and cost anomalies all alert). Test pings are excluded from every health, cost, and anomaly calculation, permanently.

Trust guarantees

Ping URLs are revocable secrets, returned only when a monitor is first created and never listed in bulk. Test pings prove the endpoint, never health. Re-running the install reconciles by a stable id derived from each job's source, path, and command, so the same job stays one monitor and re-running never duplicates or clobbers settings you customized. A removed job is marked missing for your review, never silently alerting forever, never deleted by a key.

Prefer a guided flow?

The stillrunning-mcp server wraps these same primitives as MCP tools (plan, create, wiring snippet, test ping) for Claude Code and Codex. It is optional, the curl flow above works on its own.