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.

For a Claude Code job, prefer the wrap.mjs wrapper over a bare heartbeat: node <(curl -fsSL https://stillrunning.ai/cli/wrap.mjs) "PING_URL" -- claude -p "..." runs the command unchanged and auto-captures tokens, cost, model, and tool calls from Claude's own output, so the run reports what it did, not just that it finished.

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 jobs and agents, both the ones
that run on a schedule and the ones that only run when something triggers them.
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 and event-driven 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
   - event-driven agents with no schedule at all: chatbots, RAG bots, webhook handlers,
     API-triggered agents, and Vercel eve agents
2. LIST every job you found: name, the command that runs it, and its schedule if it has one.
3. CHOOSE A MODE for each job. "scheduled" (the default) means it has an expected cadence and a
   missed run should alert. "on_demand" means it only runs when something external triggers it, so
   it carries no schedule and silence never alerts. Pick on_demand ONLY when there is genuinely no
   expected cadence. Do NOT reach for on_demand because you could not work out a job's schedule,
   that silently discards the absence detection I installed StillRunning to get. Ask me instead.
4. DRY-RUN: POST /api/v1/install/reconcile with dryRun:true and a "monitors" array where each item
   has name, mode, schedule (cron or "6h"/"30m" or seconds, omitted entirely when mode is
   on_demand), 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.
5. SHOW ME the exact files and commands you will edit to add the pings.
6. STOP and ask me to confirm. Do NOT edit my crontab, launchd, systemd, GitHub Actions, Vercel
   config, scripts, or wrappers until I say yes.
7. 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.
8. 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.
9. 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.
10. 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 → pick a mode per job → 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", "mode": "scheduled", "schedule": "0 3 * * *",
        "sourceType": "crontab", "sourcePath": "/etc/crontab",
        "command": "/usr/local/bin/backup.sh" },
      { "name": "Support chatbot", "mode": "on_demand",
        "sourceType": "agent-script", "sourcePath": "agents/support.ts",
        "command": "node agents/support.ts" }
    ]
  }'

mode decides whether silence is a problem. scheduled is the default: the job has an expected cadence, so it needs a schedule and a missed run alerts. on_demand is for an agent that only runs when something triggers it, a chatbot, a RAG bot, a webhook or API-triggered agent. It carries no schedule field at all and silence never alerts, because an agent nobody triggered is not a broken agent. Everything else is unchanged: every run still records duration, tokens, cost, and model, failures still alert, and cost anomalies, duration anomalies, and monthly budgets all still fire. Reach for on_demand only when there is genuinely no expected cadence, never as a fallback for a schedule you could not determine.

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.