Monitoring Trigger.dev with Vigilmon: Dashboard, API, Run Status & SSL

Trigger.dev is the background jobs and workflow orchestration platform that TypeScript teams use to run long-running tasks — data imports, email sequences, AI pipelines, video processing, and any workload that can't complete within a single HTTP request. When Trigger.dev's API goes down, new job triggers fail and queued runs never start. When the dashboard is unavailable, engineers can't inspect stuck runs, replay failed jobs, or diagnose why a workflow stalled mid-execution. When the trigger endpoint is unreachable, the business-critical processes that depend on it — nightly data syncs, order fulfillment workflows, user onboarding sequences — stop firing entirely. Vigilmon gives you external visibility into Trigger.dev's availability: the dashboard, API, trigger endpoint, and SSL certificate health.

What You'll Build

An HTTP monitor on the Trigger.dev dashboard to detect platform-level outages
A trigger API availability check to confirm job submission is working
A run status endpoint monitor to verify job result retrieval
SSL certificate monitoring for your Trigger.dev deployment domain
An alerting setup that distinguishes dashboard failures from job execution failures

Prerequisites

A Trigger.dev project (Trigger.dev Cloud or self-hosted trigger.dev open-source)
Your Trigger.dev dashboard URL (https://cloud.trigger.dev or your self-hosted URL)
Your Trigger.dev API base URL (https://api.trigger.dev)
A free account at vigilmon.online

Step 1: Understand Trigger.dev's External-Facing Endpoints

Trigger.dev exposes several endpoints relevant to external health monitoring:

| Endpoint | Role | |---|---| | https://cloud.trigger.dev | Dashboard — run inspection, logs, replays, scheduling | | https://api.trigger.dev/api/v1 | REST API — job triggers, run status, deployment management | | https://api.trigger.dev/api/v1/runs | Run list endpoint — confirms API connectivity | | Worker connection | WebSocket/HTTP long-poll from your app to Trigger.dev servers |

For self-hosted Trigger.dev, replace cloud.trigger.dev and api.trigger.dev with your internal domains.

Step 2: Create a Vigilmon HTTP Monitor for the Dashboard

The Trigger.dev dashboard is where engineers inspect background run logs, debug failed executions, replay stuck tasks, and manage scheduled triggers. When it's unavailable, on-call engineers can't diagnose production issues in background workflows:

curl -I https://cloud.trigger.dev
# Returns HTTP 200 with Trigger.dev dashboard HTML

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://cloud.trigger.dev (or your self-hosted Trigger.dev URL).
Check interval: 60 seconds.
Response timeout: 15 seconds.
Expected status: 200.
Keyword: Trigger (appears in the dashboard page title and content).
Click Save.

This monitor catches:

Trigger.dev Cloud platform outages
Frontend container failures in self-hosted deployments
CDN or ingress failures blocking dashboard access
Deployment failures after Trigger.dev version upgrades

Alert sensitivity: Set to trigger after 1 consecutive failure. When the dashboard is down, engineers have no visibility into background job execution status — stuck workflows go undiagnosed.

Step 3: Monitor the Trigger.dev API

Trigger.dev's REST API is the entry point for triggering jobs from your application code. When your Next.js, Express, or Node.js application calls client.sendEvent() or invokes a job, it makes an authenticated request to the Trigger.dev API. An unavailable API means every background task trigger fails silently:

# API root check — returns 401 for unauthenticated requests, confirming the API is live
curl -I https://api.trigger.dev/api/v1
# Returns HTTP 401 — confirms the API gateway is alive

Add Monitor → HTTP.
URL: https://api.trigger.dev/api/v1.
Check interval: 60 seconds.
Response timeout: 10 seconds.
Expected status: 401 (confirms the API gateway and auth layer are working).
Label: Trigger.dev API.
Click Save.

Why 401? An unauthenticated request to a protected API route returning 401 Unauthorized proves the API is reachable, routing is correct, and the auth layer is responding. A 502 Bad Gateway or connection timeout means the API backend is down — which is the failure mode you need to catch immediately.

Step 4: Monitor the Runs Endpoint

The runs endpoint (/api/v1/runs) is used to retrieve job run history and status. Application code and monitoring scripts query this endpoint to check whether background jobs completed successfully. An unavailable runs endpoint breaks post-trigger verification and job result retrieval:

curl -I https://api.trigger.dev/api/v1/runs
# Returns HTTP 401 — confirming the runs API route is live

Add Monitor → HTTP.
URL: https://api.trigger.dev/api/v1/runs.
Check interval: 2 minutes.
Response timeout: 10 seconds.
Expected status: 401.
Label: Trigger.dev Runs API.
Click Save.

Step 5: Monitor Job Trigger Endpoints (Self-Hosted)

For self-hosted Trigger.dev deployments, your instance exposes job-specific webhook trigger URLs. These are the most critical paths to monitor because they directly receive incoming events:

# Example trigger endpoint for a self-hosted deployment
curl -I https://trigger.example.com/api/v1/events
# Returns HTTP 401 — confirms event ingestion API is alive

Add Monitor → HTTP.
URL: https://trigger.example.com/api/v1/events (your self-hosted events endpoint).
Check interval: 60 seconds.
Response timeout: 10 seconds.
Expected status: 401.
Label: Trigger.dev events endpoint.
Click Save.

Trigger.dev Cloud: For cloud-hosted deployments, the event ingestion is handled by Trigger.dev's infrastructure. The API and dashboard monitors from Steps 2–3 cover the most critical paths. The runs endpoint monitor provides additional coverage for job result retrieval.

Step 6: Monitor SSL Certificates

Your application's connection to the Trigger.dev API over HTTPS requires a valid TLS certificate. An expired certificate causes the @trigger.dev/sdk client to fail with TLS errors when triggering jobs or streaming run logs:

openssl s_client -connect api.trigger.dev:443 2>/dev/null | openssl x509 -noout -dates

Add Monitor → SSL Certificate.
Domain: api.trigger.dev (or your self-hosted Trigger.dev domain).
Alert when expiry is within: 30 days.
Alert again: 14 days, 7 days, 3 days, 1 day.
Click Save.

Add a second SSL monitor for cloud.trigger.dev if your engineers access the dashboard regularly — an expired dashboard certificate triggers browser security warnings that block access.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Dashboard | Non-200 or keyword missing | Check Trigger.dev status page; alert on-call; notify engineering team | | REST API | Non-401/non-200 | Job triggers failing; check API server health; inspect self-hosted logs | | Runs API | Non-401/non-200 | Run retrieval broken; post-trigger verification failing | | Events endpoint | Non-401/non-200 | Event ingestion down; incoming triggers not being queued | | SSL certificate | < 30 days to expiry | Renew certificate; test SDK connectivity after renewal |

Alert after: 1 consecutive failure for the dashboard and REST API monitors. 2 consecutive failures for the runs and events monitors.

Common Trigger.dev Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Trigger.dev Cloud platform outage | Dashboard and API monitors fire; all job triggers fail | | API gateway overloaded (5xx) | REST API monitor fires; SDK triggers return errors | | Self-hosted container OOM killed | All monitors fire; no jobs can be triggered or queried | | Worker disconnected from Trigger.dev server | Not caught by HTTP monitoring; jobs queue but don't execute | | Database backend failure | API may respond but job persistence fails; API monitor may catch via 5xx | | SSL certificate expiry | SSL monitor alerts; SDK connections fail with TLS errors | | Deployment misconfiguration | Dashboard and API monitors fire simultaneously | | Run storage backend failure | Runs API monitor catches; historical runs inaccessible | | Rate limiting (429 on high volume) | Not directly caught; configure Trigger.dev SDK retry logic | | DNS failure | All monitors fire simultaneously |

Monitoring Worker Connectivity

Vigilmon monitors the Trigger.dev server endpoints — the API and dashboard that your application and workers connect to. Worker health (whether your Node.js processes are connected to Trigger.dev and polling for work) is a separate concern:

Worker process monitoring: Use your process manager (PM2, systemd, Kubernetes) to ensure worker processes stay running. A crashed worker process disconnects from Trigger.dev silently.
Run execution monitoring: Trigger.dev's dashboard shows stuck runs (runs that have been QUEUED or EXECUTING for longer than expected). Set up regular checks in your monitoring routine.
Dead jobs: Trigger.dev captures failed runs with full error traces in the dashboard. Consider setting up periodic checks for runs in FAILED status using the Runs API if you have critical workflows.

Vigilmon catches infrastructure-level failures (API down, dashboard unreachable, certificate expired). Worker health and job execution correctness require application-level monitoring via Trigger.dev's dashboard and SDK observability.

Trigger.dev is the execution backbone for every background workload in your TypeScript application — nightly syncs, AI pipelines, email sequences, file processing, and any task your users trigger that can't wait for a synchronous response. When Trigger.dev's API goes down, those tasks silently stop firing. When the dashboard is unavailable, engineers can't diagnose why a critical workflow stalled. Vigilmon gives you external visibility into Trigger.dev's availability from outside your infrastructure: API health, dashboard uptime, run endpoint access, and SSL certificate expiry, so you know the moment Trigger.dev becomes unreachable and can restore background job execution before your users notice the silence.

Start monitoring Trigger.dev in under 5 minutes — register free at vigilmon.online.