Monitor Trigger.dev scheduled tasks: alerts for failed and missed runs

Setup: onSuccess and onFailure hooks

Ping on success, POST the error to /fail on failure. A matching monitor schedule catches the run that never triggered.

https://ping.lastping.dev/<your-monitor-id>

import { schedules } from "@trigger.dev/sdk";

const PING = "https://ping.lastping.dev/<your-monitor-id>";

export const nightlyEtl = schedules.task({
  id: "nightly-etl",
  cron: "0 3 * * *",
  maxDuration: 1800, // seconds: a hung run ends as Timed out
  onSuccess: async () => {
    await fetch(PING);
  },
  onFailure: async ({ error }) => {
    await fetch(`${PING}/fail`, {
      method: "POST",
      body: String(error).slice(0, 10000),
    });
  },
  run: async (payload) => {
    // your work; payload.timestamp is the scheduled time
  },
});

  onStartAttempt: async ({ ctx }) => {
    if (ctx.run.attempt.number === 1) {
      await fetch(`${PING}/start?rid=${ctx.run.id}`);
    }
  },
  onSuccess: async ({ ctx }) => {
    await fetch(`${PING}?rid=${ctx.run.id}`);
  },

What this catches

• ✓A run fails after its retries: onFailure pings /fail with the error; you're paged immediately.
• ✓A run that hangs: it ends as Timed out at maxDuration, or with a /start ping the grace window fires first.
• ✓A run that never leaves the queue: it ends as Expired once its TTL passes; no success ping arrives, so the incident opens.
• ✓A task missing from the current deployment, or a deactivated schedule: no run, no ping, incident.
• ✓Recovery: the next successful run closes the incident automatically.

Comparing orchestrators? See Monitoring failed workflows across orchestrators. Using Inngest instead? See Inngest functions. Hatchet? See Hatchet workflows. For the base pattern, see Monitor Node.js scripts.

Questions people ask

Front-loaded answers: the most important fact first.

• Doesn't Trigger.dev already alert on failed runs?

  Yes. The Alerts page can notify you by email, Slack or webhook when a run fails or a deployment fails, and an onFailure hook can send anything you like. Those cover runs that happened. Trigger.dev's docs list two cases where a scheduled task does not trigger at all: in Dev, when the dev CLI is not running, and in Staging or Production, when the task is not in the current deployment. A deactivated schedule also creates no runs. A dead-man's-switch expects a check-in on every scheduled run and opens an incident when one is missing.

• How do I add a dead-man's-switch to a Trigger.dev scheduled task?

  Add onSuccess and onFailure to the schedules.task() definition. In onSuccess, GET https://ping.lastping.dev/<id>; in onFailure, POST the error to the /fail path. Create a LastPing monitor with the same cron as the task's schedule so a run that never triggers also alerts.

• When does onFailure run?

  Only once the run has exhausted all its retries, so a transient error that a retry fixes does not page you. Errors thrown inside onFailure or onSuccess are ignored by Trigger.dev, so a failed ping never fails your task.

• What about a run that hangs or never leaves the queue?

  A run that exceeds its maxDuration ends as Timed out, and a run whose TTL passes before it starts ends as Expired. In both cases onSuccess never runs, so LastPing sees no success ping and opens the incident when the grace window ends. An optional /start ping from onStartAttempt also records how long each run took.

• Is this free?

  Yes. LastPing is free for individuals. See vs Healthchecks.io and vs Cronitor.