Most monitoring watches a thing and tells you when it looks wrong. LastPing waits for a thing to check in and tells you when it doesn't. That inversion is the whole product: a job that breaks can't send you an error, but it can fail to send you anything — and absence is the one signal a broken process can still produce.

This repository holds the open-source pieces: the lastping CLI and the MCP server. The hosted service they talk to is at lastping.dev, free for individuals.

Install

curl -fsSL https://raw.githubusercontent.com/tp322d/lastping-app/main/install.sh | sh

No Go toolchain needed — that pulls a prebuilt binary for macOS and Linux, on amd64 and arm64, and verifies its checksum. Windows builds are on the releases page.

If you do have Go:

go install github.com/tp322d/lastping-app/cmd/lastping@latest

`lastping run` — reporting you can't forget

Put it in front of whatever you already run:

lastping run --monitor <monitor-id> -- python nightly_etl.py
lastping run --monitor <monitor-id> -- ./backup.sh
lastping run --monitor <monitor-id> -- claude

It sends a start ping, runs your command untouched, and reports the exit code when it finishes — success on 0, failure on anything else, with the tail of stderr attached so the alert says why.

Three properties worth knowing, because they are the difference between a monitoring wrapper you can trust in production and one you remove after a bad night:

Your exit code always propagates. The wrapper exits with whatever your command exited with, so CI behaves exactly as it did before you added it.
A failed ping never touches your command. If LastPing is unreachable, your job still runs, still writes its output, still exits normally.
Interactive stays interactive. stdin and stdout are handed over as file descriptors, so wrapping a REPL or an agent session works.

Why a wrapper rather than an instruction? Because anything advisory decays. An AI agent told to report on every task will stop doing it, and a cron line you meant to add a curl to never gets it. A wrapper reports from the process lifecycle, so nothing depends on anybody remembering.

MCP server — let an agent set up its own monitoring

// claude_desktop_config.json, .mcp.json, or your client's equivalent
{
  "mcpServers": {
    "lastping": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.lastping.dev/mcp",
               "--header", "Authorization: Bearer ${LASTPING_API_KEY}"],
      "env": { "LASTPING_API_KEY": "lp__your_key_here" }
    }
  }
}

The hosted server is the recommended path — nothing to install, and it always carries the current tool set.

A stdio binary is also here if you would rather run it yourself:

go install github.com/tp322d/lastping-app/cmd/lastping-mcp@latest

Tools in this repository's stdio binary (36)

Monitors: create_monitor · get_monitor · list_monitors · update_monitor · delete_monitor · pause_monitor · resume_monitor · snooze_monitor

Discovery: discover_monitors_reconcile

Reporting: get_ping_instructions · declare_run_expectations

Incidents & runs: list_incidents · get_run_history

The failure loop: list_open_incidents · add_incident_note

Alert routing: set_route

Destinations: list_destinations · create_destination · update_destination · test_destination · delete_destination

Alert templates: get_alert_templates · set_alert_template

Agent registry: register_agent · list_agents · get_agent · update_agent · delete_agent

Status pages: list_status_pages · create_status_page · update_status_page · delete_status_page

API keys: create_api_key · list_api_keys · revoke_api_key

Terraform: export_terraform

This binary carries the same tool set as the hosted server at mcp.lastping.dev. It is a thin REST client throughout: every tool is a direct HTTP call to the management API, so it stays free to run yourself with no lag behind the hosted surface beyond a new release.

The one that matters most is get_ping_instructions: an agent calls create_monitor, then asks for its own ping commands, and wires them into its own work — in one conversation, without a human opening a dashboard.

Ping API

Every monitor gets a URL. There is nothing to install and no library to keep current; anything that can make an HTTP request can report.

What happened	Request
finished successfully	`POST <ping-url>`
started a run	`POST <ping-url>/start`
failed	`POST <ping-url>/fail` with the error as the body
exited with a code	`POST <ping-url>/<exit-code>`
waiting on a human	`POST <ping-url>/blocked`
progress worth recording	`POST <ping-url>/note`

Add ?rid=<id> to pair a run's start with its result, so LastPing can group a run's pings and time it.

# The classic one-liner, at the end of a cron job:
curl -fsS -m 10 --retry 3 https://ping.lastping.dev/<monitor-id>

Monitoring as code

resource "lastping_monitor" "nightly_etl" {
  name          = "nightly-etl"
  slug          = "nightly-etl"
  schedule_kind = "cron"
  cron_expr     = "0 3 * * *"
  tz            = "Europe/Berlin"
  grace_s       = 900
}

The provider is on the Terraform Registry as lastping-dev/lastping, with source at lastping-dev/terraform-provider-lastping.

License

MIT. See LICENSE.

LastPing