get_ping_instructions
Get everything needed to make a monitor report: the ping URL, copy-paste check-in snippets, and reporting mechanisms. Use it right after creating a monitor to start monitoring.
Instructions
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. Re-running hook_install replaces an older ~/.claude/lastping-report.sh (keeping a .bak), which is how an existing install is upgraded. 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. To send OpenTelemetry traces, read tracing_how_to, call get_trace_setup with the tool that sends the telemetry and carry its steps out yourself; the tracing key comes from create_ingest_key, never from your own API key. otel_env_lines is the minimal form: the export lines (OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_RESOURCE_ATTRIBUTES, OTEL_EXPORTER_OTLP_HEADERS) to set in the child process's environment so its spans arrive on this monitor; fill in the tracing key placeholder yourself, it is not resolved server-side. An exporter that cannot set headers can instead POST straight to <ping_url>/v1/traces: the monitor-URL form needs no Authorization header at all, since the monitor id in the URL is itself the capability.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor UUID (from create_monitor or list_monitors). |