Monitor CrewAI: dead-man's-switch for scheduled multi-agent crew runs

CrewAI crews fail silently across three dimensions.

A multi-agent crew is harder to observe than a single agent: failures can happen in any agent's tool, at task delegation boundaries, or at the level of the overall run that never happens at all.

Setup: three lines around crew.kickoff()

No CrewAI plugin, callback, or flow change needed. The watchdog wraps the entire run from outside, exactly where the boundary failures occur.

https://ping.lastping.dev/<uuid>

import requests
from crewai import Crew, Agent, Task

PING_URL = "https://ping.lastping.dev/<uuid>"

def run_crew():
    requests.get(f"{PING_URL}/start", timeout=10)   # arm watchdog
    try:
        result = my_crew.kickoff()
        requests.get(PING_URL, timeout=10)           # signal success
        return result
    except Exception as exc:
        requests.post(
            f"{PING_URL}/fail",
            data=f"Crew failed: {type(exc).__name__}: {exc}",
            headers={"Content-Type": "text/plain"},
            timeout=10,
        )
        raise

import httpx

async def run_crew_async():
    async with httpx.AsyncClient() as client:
        await client.get(f"{PING_URL}/start", timeout=10)
        try:
            result = await my_crew.kickoff_async()
            await client.get(PING_URL, timeout=10)
            return result
        except Exception as exc:
            await client.post(
                f"{PING_URL}/fail",
                content=f"Crew failed: {type(exc).__name__}: {exc}",
                headers={"Content-Type": "text/plain"},
            )
            raise

import uuid, requests

rid = uuid.uuid4().hex
requests.get(f"{PING_URL}/start", params={"rid": rid}, timeout=10)

for task in crew.tasks:
    run_one(task)
    requests.get(f"{PING_URL}/step",
                 params={"rid": rid, "step": task.name}, timeout=10)

requests.get(PING_URL, params={"rid": rid}, timeout=10)

What this catches

The same durable detection engine as LastPing's cron monitoring: deadlines live in the database, restarts never miss a due check.

• ✓Crews that never run: scheduler failure, OOM kill, expired API key. No start ping in the expected window → incident.
• ✓Hung crews: an agent's tool call never returns; crew.kickoff() blocks; overrun detection opens an incident after the grace window.
• ✓Stalled runs: with step reporting enabled, a run that stops making progress opens an incident naming the task it wedged in, without waiting out the whole run budget.
• ✓Crew exceptions: the except block fires immediately, POSTing the exception type and message (up to 10,000 bytes) to the incident.
• ✓Recovery: the next successful kickoff closes the incident automatically.
• ✓Agent self-registration: a crew agent can create its own LastPing monitor via MCP and wire the pings into the kickoff wrapper.

The same pattern applies to OpenAI Agents SDK and LangChain agents. For CI/CD pipelines, see GitHub Actions or the monitoring guides index. The LastPing MCP server at mcp.lastping.dev lets agents self-register their own monitors in a single conversation.

Questions people ask

Front-loaded answers: the most important fact first.

• How do I monitor a CrewAI crew running on a schedule?

  Wrap crew.kickoff() with a start ping before, a success ping after, and a fail POST in the exception handler. Create a heartbeat monitor in LastPing with your schedule, so a run that never starts also opens an incident, and a grace window that accounts for how long the crew typically runs. Or add the LastPing MCP server to your crew's available tools and let it self-register. Free for individuals, no monitor cap.

• Why does a multi-agent crew need a longer grace window?

  A single agent might complete a task in seconds; a research crew with multiple agents doing web searches, writing drafts, and reviewing output might legitimately run for 20-40 minutes. Set the grace window in LastPing to your crew's 95th-percentile runtime so occasional slow runs don't trigger false alerts.

• What causes CrewAI crews to hang?

  CrewAI crews can hang when an individual agent within the crew blocks on a tool call: a slow API, a search tool that doesn't time out, a code execution environment that freezes. The crew's task delegation loop waits for the blocked agent, crew.kickoff() never returns, and no exception propagates. The start ping fires but the success ping never arrives, so overrun detection opens an incident after the grace window.

• Can a CrewAI agent add LastPing monitoring to the crew itself?

  Yes. Add the LastPing MCP server at mcp.lastping.dev as an available MCP server in your CrewAI configuration, or include a LastPing Tool (a tool wrapped in a CrewAI Tool class) in the crew's tool list. An agent in the crew can then call create_monitor and get_ping_instructions to create a heartbeat watchdog and receive the curl commands to embed in the crew's own kickoff wrapper. The crew instruments its own watchdog, with no human dashboard visit required.

• Does this work with the @crew decorator and CrewAI Flows?

  Yes. Whether you use the @crew decorator (CrewAI's flow-based API) or construct the Crew object directly, the kickoff() method is the call to wrap with pings. For CrewAI Flows using the @start() decorator, wrap the flow's entry method the same way: start ping at the top, success ping at the end, fail POST in an exception handler. The same heartbeat monitor catches missed flow executions and flow-level exceptions.

• Is CrewAI monitoring free in LastPing?

  Yes. LastPing is free for individuals with no monitor cap. The MCP server at mcp.lastping.dev is included. OpenAI Agents SDK and LangChain agents use the same pattern: see OpenAI Agents SDK monitoring and LangChain monitoring.