AI agent monitoring: catch a stalled run, not just a crash

LastPing tells you when an AI agent has stopped making progress — not just when it has crashed.

How do you know if an agent is stuck rather than still working? You cannot tell from the process. A stalled agent holds its connection, keeps its memory resident and passes every health check — it looks identical to one thinking hard about a difficult step. The signal that separates them is progress: LastPing has the agent report each completed step, and opens an incident when the next one does not arrive in time.

That is the whole idea. Watch for the arrival of an expected signal rather than for an error, because a stalled run never produces an error to catch.

What a stall actually looks like

These are the shapes it takes:

• Ran all night, did nothing. The process was up the whole time. No error was raised, because nothing failed — the run simply stopped advancing.
• Stuck on "running". The status is accurate and useless. It has been running for six hours; it was supposed to take four minutes.
• Hung mid-step. A tool call or API request never returned, and nothing above it had a deadline.
• Queued and never started. The run was accepted and then never picked up. The absence of a start is the only signal there was.

Each one produces the same output: silence. Monitoring that waits for an error will wait indefinitely, because no error is coming.

Four signals, and why progress is the one that matters

An agent reports four things to LastPing: started, progress, blocked, and failed.

Failed is the easy one — it is the case that already alerts you today. Started catches the run that never began. Blocked catches the agent waiting on a human who has gone home.

Progress is the signal that catches a stall. It moves the question from is the process alive to is the work advancing, and those are different questions with different answers. An agent looping over the same reasoning step is alive by every infrastructure measure and has been stationary for an hour. Give the run a deadline for its next progress signal, and when that deadline passes with the process still healthy, LastPing opens an incident.

Source: LastPing.

The agent can set up its own monitor

LastPing runs an MCP server, so an agent can create and instrument its own monitor in the same conversation where it is given the task — then run unattended against it. No dashboard, no separate provisioning step, no human remembering to add the check afterwards.

The command-line tool and the MCP server are open source under the MIT licence.

Source: github.com/tp322d/lastping-app · checked 25 August 2026.

Monitors defined in Terraform

Monitors belong in the same place as the infrastructure they watch. The LastPing Terraform provider is published on the HashiCorp Terraform Registry, so a monitor is created, reviewed and versioned like any other resource — and a monitor that is missing from the plan is visible in review, before it is missing in production.

Source: registry.terraform.io/providers/lastping-dev/lastping and the provider's release history · checked 25 August 2026.

The jobs underneath the agent

An agent is rarely alone. It sits on top of scheduled work — the nightly backup, the sync job, the CI pipeline that rebuilds its index — and any of those can stop without announcing it, taking the agent down with them by degrees.

LastPing watches those the same way, because it is the same mechanism: something checks in on a schedule, and the alarm is the absence of the expected signal rather than the presence of an error.

*/5 * * * * /path/to/job.sh && curl -fsS https://ping.lastping.dev/<your-monitor-id>

Cron jobs and backups check in over a ping URL. CI pipelines report through a signed webhook, so a run that fails, hangs, or never starts is caught without editing the pipeline definition. HTTP endpoints are checked for status, latency and expected content.

Source: LastPing.

Who builds it

LastPing is built by Tedo Patsatsia, a systems engineer working in DevOps — which is to say it is built by someone who has been on the receiving end of a job that stopped running three weeks before anyone noticed.

That background is the reason the product is shaped the way it is: the absence of a signal is treated as the event, alerts are routed rather than accumulated, and monitors live in version control instead of a console.

Source: LastPing.

Where LastPing is not the right tool

LastPing is not built for life-safety or mission-critical systems, and should not be used as a safeguard for them.

It is also not an APM: it does not collect metrics, logs or distributed traces, and it does not replace a tracing tool that shows you what your agent was reasoning about. It answers a narrower question — has the work advanced — and leaves the rest to tools built for it. It is available as a hosted service.

Price

Free for individuals, no cap. No monitor limit, no credit card, fully hosted.

Source: LastPing.

Questions

How do I know if my AI agent is stuck instead of still working?

Ask for a progress signal rather than a health check. A stuck agent passes every health check — the process is running and responsive. Set a deadline for the next reported progress step; when the deadline passes and no step has been reported, the run is stalled regardless of how healthy the process looks.

My agent ran all night and did nothing — how do I catch that next time?

Give the run an expected cadence and a maximum duration. LastPing opens an incident at the first missed progress deadline instead of at the end of the run, so the alert arrives during the night rather than the following morning.

My agent is stuck on "running" — how do I detect that automatically?

"Running" is a state, not a signal. Instrument the agent to report each completed step; the gap between reported steps is the measurement. When that gap exceeds what the task should take, the run is flagged.

How do I tell the difference between an agent thinking and an agent hung?

By elapsed time since the last completed step, not by whether the process responds. A thinking agent still finishes steps; a hung one stops finishing them while remaining perfectly responsive.

How do I monitor an agent that runs unattended overnight?

The agent reports started, progress, blocked and failed as it goes. If the expected signal does not arrive inside its window, LastPing opens an incident and routes the alert to wherever you are — Slack, Discord, Telegram, Teams, Google Chat, a webhook, ntfy or Pushover.

My agent execution is queued and never starts — how do I get notified?

The started signal covers this. If a run is expected and no start arrives inside its window, the missing start is the incident.

What should alert me when an autonomous agent stops making progress?

A missed progress deadline. Not CPU, not memory, not process liveness — those all look normal during a stall.

How do I signal started, progress, blocked and failed from an agent?

Over the MCP server, in which case the agent can instrument itself; over the command-line tool; or with a plain HTTP request from whatever the agent is written in. There is no SDK to adopt and no language requirement.