What AI agent failures does LastPing detect?

LastPing detects silent death (the agent process ends without reporting), hangs (the agent started but never finished within the expected window), runaway loops (an alert if pings arrive far more often than expected), and scheduled agent runs that silently stop firing. These are outside-in liveness checks — no SDK required inside the agent.

How does an AI agent set up its own LastPing monitor?

Install the lastping-mcp server (a single Go binary). In one conversation, tell the agent to create a monitor for itself: it calls create_monitor to register a heartbeat, then get_ping_instructions to receive the curl_success / curl_start / curl_fail snippets, and adds them to its own workflow. The whole loop — create, instrument, verify — takes one conversation and zero dashboards.

Is LastPing free for monitoring AI agents?

Yes. LastPing is free for individuals — no monitor cap, no feature gate. A paid team tier may be introduced later for teams running fleets of agents.

What MCP tools does lastping-mcp expose?

create_monitor (upsert-by-slug, safe to retry), list_monitors, get_monitor, update_monitor, delete_monitor, pause_monitor, resume_monitor, snooze_monitor, list_incidents, get_incident, list_destinations, create_destination, test_destination, set_route (route a monitor's down/recovery/fail alerts to destinations), and get_ping_instructions — which returns the ping URL and ready-to-run curl_success / curl_start / curl_fail snippets for any monitor.

AGENT-FIRST · MCP SERVER · FREE FOR INDIVIDUALS

The dead man's switch for everything that runs without you —
including your AI agents.

An autonomous agent is the new cron job. It runs unattended, on a schedule or a loop, and its worst failures are silent — the process is alive, the work has stopped. LastPing is the first monitor your agent can set up itself, via MCP, in one conversation.

Start monitoring — free MCP install guide

Agents fail silently. For the same reasons cron jobs do.

The failure class that makes cron monitoring necessary — silent absence of a signal that should have arrived — applies to AI agents word for word. Four modes, zero notifications.

Failure mode 01

Silent death

The agent process exits — crash, OOM, unhandled exception — and nothing in your stack notices. The operator assumes it's running. It has been dead for hours.

Failure mode 02

The hung run

The agent started. It hasn't finished. The process is alive by every health check — event loop not frozen, memory stable — but it has been waiting on a tool call, a token, or an external API for 90 minutes. Nobody gets paged.

Failure mode 03

The runaway loop

The agent is alive and running — but it has looped far beyond what any successful run should take, burning tokens and compute indefinitely. Too many pings is also a signal.

Failure mode 04

Scheduled runs that stop

Your nightly agent ran reliably for three weeks, then silently stopped. The scheduler is fine; the trigger condition stopped being met; no one noticed. Absence detection is the fix.

LLM-observability tools (LangSmith, Langfuse, AgentOps) instrument inside the agent — traces, tokens, evals — and answer "is the output good?" LastPing is outside-in: it answers "did the agent run at all, finish in time, and not loop forever?" That question is unowned. LastPing's dead-man's-switch primitive handles it without any SDK or language dependency — the same curl -fsS https://ping.lastping.dev/<id> that works in crontab works in an agent's tool call.

The flagship: the agent that monitors itself

Via the MCP server, an agent in Claude Code, Cursor, or any MCP-enabled client can create its own dead-man's-switch and wire in the pings — in one conversation, without opening a dashboard.

You

Set up a LastPing dead-man's-switch for yourself so I know if this nightly run goes silent or hangs.

Agent (via MCP)

create_monitor({ "name": "nightly-summary-agent", "slug": "nightly-summary-agent", "schedule": "0 2 * * *", "grace_seconds": 1800 }) → monitor created · ping URL: https://ping.lastping.dev/<id>

Agent (via MCP)

get_ping_instructions({ "monitor_id": "<id>" }) → curl_start: curl -fsS .../<id>/start curl_success: curl -fsS .../<id> curl_fail: curl -fsS .../<id>/fail

You

Monitor created. The agent now pings on start, success, and failure. If it hangs or goes silent, LastPing opens an incident and emails you.

Connect your agent in about a minute

Hosted and remote — add a URL and your API key, nothing to install. Works with Claude Desktop, Claude Code, Cursor, and any client that supports the Model Context Protocol. Prefer local? Self-host the stdio binary instead.

Get a LastPing API key

Sign in at app.lastping.dev, then go to Settings → API Keys and create a key. Copy it — you'll need it in the next step.

Add to your MCP client config

Point your client at the hosted server — nothing to install, no local process. For Claude Desktop add to claude_desktop_config.json; for Claude Code or a project, add to .mcp.json:

{ "mcpServers": { "lastping": { "url": "https://mcp.lastping.dev", "headers": { "Authorization": "Bearer lp_your_key_here" } } } }

Prefer to self-host? Run the stdio binary locally with go install github.com/tp322d/lastping-app/cmd/lastping-mcp@latest, then use "command": "lastping-mcp" and "env": { "LASTPING_API_KEY": "lp_…" } instead of the URL.

Ask the agent to instrument itself

Restart the client. The agent now has access to create_monitor, get_ping_instructions, and the full tool set. In a conversation:

# Example prompt to kick off self-instrumentation: "Create a LastPing monitor for this task (schedule: every 6 hours, grace: 30 minutes). Then get the ping instructions and wire the start/success/fail pings into the workflow."

get_ping_instructions is the key tool — it returns the exact curl_success, curl_start, and curl_fail snippets for the monitor the agent just created. From that point on, any silent failure opens a LastPing incident and alerts you.

What LastPing catches for agents

The same durable detection engine as LastPing's cron and CI/CD monitoring — deadlines in the database, never in-memory timers.

Silent death — the agent crashes or exits without sending a success or fail ping. No signal in the expected window → incident.
Hung runs — the agent sent a start ping but never sent success or fail within the grace window. Silence after start → incident.
Explicit failures — the agent POSTs to /fail with the error body. Incident opens immediately with the failure detail attached.
Scheduled runs that stop — expected on a cron or interval; if no run signal arrives in the window, LastPing opens an incident. The scheduler being "up" is not enough.
Recovery — the next successful ping closes the incident and sends a recovery notice automatically.

The full ping API: GET /<id> (success) · /<id>/start (run began — arms overrun detection) · /<id>/fail (POST failure body as text/plain) · /<id>/<exit-code> (0 = success, non-zero = fail) · ?rid=<run-id> (pair start with its later result and record duration). See the full reference at app.lastping.dev/docs/api/ or in agents.md.

What the MCP server exposes

Verified against cmd/lastping-mcp — every tool listed here is implemented and ships in the binary.

Monitors — create_monitor (upsert-by-slug, safe to retry) · list_monitors · get_monitor · update_monitor · delete_monitor · pause_monitor · resume_monitor · snooze_monitor
Incidents — list_incidents · get_incident (includes CI failure detail — the "why it failed")
Destinations — list_destinations · create_destination (email, Slack, Discord, Telegram, webhook, ntfy, Pushover, Teams, Google Chat) · test_destination
Routing — set_route sends a monitor's down / recovery / fail alerts to one or more destinations (replaces the set; empty clears it)
Self-instrumentation — get_ping_instructions returns the monitor's ping URL plus ready-to-run curl_success / curl_start / curl_fail snippets. This is the tool that makes one-conversation self-instrumentation possible.

Questions

Front-loaded answers — the most important fact first.

What AI agent failures does LastPing detect?

LastPing detects four classes of agent failure: silent death (process exits without a ping), hangs (start ping sent, no success/fail within the grace window), explicit failures (agent posts to /fail with the error body), and scheduled runs that stop (no signal in the expected cron window). These are outside-in liveness checks — no SDK or language binding required.
How does an AI agent set up its own monitor?

Install the lastping-mcp server (a single Go binary, no npm). In one conversation, tell the agent to create a monitor for itself: it calls create_monitor, then get_ping_instructions to receive the exact curl snippets, and wires them into its own workflow. The whole loop — create, instrument, verify — takes one conversation and zero dashboards.
Do I need an SDK or library inside the agent?

No. The ping API is plain HTTP — a curl GET or POST from any language or shell. The MCP server is for creating and managing monitors, not for pinging them. Once a monitor exists, the agent pings by making a plain HTTP request — no dependency, no import.
Is LastPing free for monitoring AI agents?

Yes. LastPing is free for individuals — no monitor cap, no feature gate. Every monitor type is available at no cost. A paid team tier may be introduced later for teams running fleets of agents.
How is this different from LLM-observability tools like LangSmith?

LLM-observability tools (LangSmith, Langfuse, AgentOps, Coralogix AI Center) instrument inside the agent — traces, token counts, evals, guardrails — and answer "is the output good?" LastPing is outside-in and answers "did the agent run at all, finish in time, and not loop forever?" Those are different questions. LastPing requires no SDK; any agent that can make an HTTP request can use it.
Which MCP clients does lastping-mcp support?

Any client that speaks the Model Context Protocol over stdio: Claude Desktop, Claude Code, Cursor, Windsurf, and others. Configure it in claude_desktop_config.json (for Claude Desktop) or a project-level .mcp.json (for Claude Code and Cursor).