get_ping_instructions

dev.lastping/lastping · Verify this server

Requires an API key with the read scope or higher. Get everything needed to make a monitor actually report: the ping URL, copy-paste check-in snippets, and the three MECHANISMS for reporting, returned together. Call this right after create_monitor. CHOOSE BY WHAT THE MONITORED THING IS — read `reporting_options` first and pick by that, rather than defaulting to the raw curl list: `how_to` — the manual protocol — is the UNIVERSAL path: it works in any agent, any language, any tool, with no prerequisite, so it is the default choice for any agent this applies to. Pair it with expect_every_s (the silence floor, set via update_monitor) so an agent that quietly stops reporting opens a detected incident instead of leaving its monitor reading healthy. If you ARE Claude Code specifically, `hook_install` is available as an OPTIONAL SHORTCUT, not a better tier: a one-time install that binds reporting to Claude Code's own hooks (UserPromptSubmit, Stop, StopFailure), automating how_to's exact same protocol so reporting becomes a property of your event loop instead of something you must remember — and it is the only mechanism that can send every state this product models, including blocked and note. hook_install is Claude Code specific: if you are a DIFFERENT AI agent — even one with its own hook or event system, Cursor, Windsurf, Codex, a custom framework — do NOT translate its steps into your own hooks; the event semantics differ and a translated install can pass its own verification while never reporting, so use `how_to` instead. If what you are monitoring is launched as a command instead — a cron job, a CI step, a script, or an agent started from a shell — use `run_wrapper`: wrap the command with `lastping run` and a separate process reports for you, so nothing has to be remembered; the tradeoff is that it reports the process's own lifecycle (start, success, fail, cancel) and has no way to send blocked or note. Whichever you choose, the underlying protocol is the same: the success ping at the END of the work, the fail URL if it failed, the start ping first for long or possibly-hung runs (this enables overrun / never-finished detection), and a step (curl_step) as each stage completes so a run that wedges mid-way is caught by name rather than only when its whole budget expires. Also read `expectations_how_to`: before you start work, use declare_run_expectations to say how THIS run should be judged when it closes — a one-time, unchangeable commitment that replaces the run grading itself. And `discovery_how_to`, which is about the OTHER jobs on this host or in this repo: how to find the scheduled work nobody is watching yet and propose it, rather than monitoring only the one thing you were asked about.