tp322d/lastping-app

never start, and watches the cron jobs and CI/CD pipelines around them. Free
for individuals.
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 client pieces: the lastping CLI, which wraps
any command and reports its start, exit code and traces, and the MCP server,
which lets an AI agent set up and read its own monitoring. The hosted service
they talk to is at **lastping.dev**, free for
individuals.
Quick start
Create the monitor, and get its id, at app.lastping.dev,
or let your assistant do it over MCP. Connect steps for each client are at
lastping.dev/mcp/.
Install
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:
lastping run — reporting you can't forget
Put it in front of whatever you already run:
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.
Traces
lastping run always configures your wrapped command's OpenTelemetry
exporter, in its environment only, so an auto-instrumented agent can export
its own trace spans with no code change:
- OTEL_EXPORTER_OTLP_TRACES_ENDPOINT — the header-free monitor-URL form
( /v1/traces) when LASTPING_API_KEY is not set, so a headerless
exporter can still authenticate; the ping host's /v1/traces (the Bearer
form) when it is set.
- OTEL_RESOURCE_ATTRIBUTES — lastping.monitor_id= ,lastping.run_id=
appended to whatever you already set, so a trace's spans join the same run
the surrounding pings report.
- OTEL_EXPORTER_OTLP_HEADERS — Authorization=Bearer , only when
LASTPING_API_KEY is set and you have not already set that variable
yourself.
Any of the three you already set is left alone. The key is never used to
authenticate a ping; the ping URL stays unauthenticated by design, as above.
MCP server — let an agent set up its own monitoring
Claude Desktop extension
A one-click install for Claude Desktop on macOS and Windows that keeps your
key in the system keychain. It needs no Node.js.
1. Download lastping.mcpb.
2. Double-click it; Claude Desktop opens its install dialog.
3. Paste a write-scope key from Settings, API keys at
app.lastping.dev.
The extension runs this repository's stdio binary (below) on your computer.
It is built by mcpb/build.sh when a version is tagged, and every release is
signed; the release build fails rather than ship an unsigned bundle. The
certificate is self-signed, so Claude Desktop shows the extension as