tutorial

Monitoring Inngest with Vigilmon: Event API, Function Endpoint, Dashboard & SSL

How to monitor Inngest with Vigilmon — event API availability, function serve endpoint health, dashboard uptime, and SSL certificate monitoring for durable workflow infrastructure.

Inngest is the event-driven workflow and background function platform that engineering teams use to orchestrate durable, multi-step processes — onboarding sequences, payment retries, scheduled jobs, fan-out pipelines, and any logic that needs automatic retry, state management, and step-based execution. When Inngest's event API goes down, new events aren't ingested and no functions fire. When your function serve endpoint is unreachable, Inngest can't invoke your functions — meaning every queued step and retry silently fails. When the dashboard is unavailable, engineers can't inspect failed runs, replay events, or debug step-level errors. Vigilmon gives you external visibility into Inngest's availability: the event API, your function serve endpoint, the dashboard, and SSL certificates.

What You'll Build

  • An HTTP monitor on the Inngest event API to detect ingestion failures
  • A function serve endpoint monitor to confirm Inngest can reach your application
  • A dashboard availability check for the Inngest Cloud dashboard
  • SSL certificate monitoring for your application's function serve endpoint
  • An alerting setup that distinguishes Inngest platform failures from application-side serve endpoint failures

Prerequisites

  • An Inngest project (Inngest Cloud or self-hosted Inngest)
  • Your application's Inngest serve endpoint URL (e.g., https://yourapp.com/api/inngest)
  • The Inngest Cloud API URL (https://api.inngest.com)
  • A free account at vigilmon.online

Step 1: Understand Inngest's Architecture

Inngest works differently from traditional job queues. Instead of workers polling a queue, Inngest calls your application's HTTP endpoint to invoke functions:

| Component | Role | Who hosts it | |---|---|---| | Inngest Event API | Receives events from inngest.send() calls | Inngest Cloud / your self-hosted Inngest | | Inngest Dashboard | Inspect runs, replay events, manage functions | Inngest Cloud / self-hosted | | Function serve endpoint | Your application's HTTP handler (/api/inngest) | Your application server | | Step execution | Inngest calls your serve endpoint for each step | Inngest → your server |

This architecture means two sets of things need to be healthy: the Inngest platform (event ingestion, orchestration, dashboard) and your application's serve endpoint (reachable by Inngest's servers). Vigilmon can monitor both sides.

Step 2: Monitor the Inngest Event API

The Inngest event API receives events sent by your application code (inngest.send()). When it's unreachable, no events are ingested and no functions fire — your workflows stop triggering entirely:

# Event API — an unauthenticated probe returns 401 or a validation error
curl -I https://api.inngest.com/e/test
# Returns HTTP 401 — confirms the event API is alive
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://api.inngest.com/e/test.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 401 (unauthenticated request confirms API routing and auth layer are working).
  6. Label: Inngest Event API.
  7. Click Save.

This monitor catches:

  • Inngest Cloud platform outages affecting event ingestion
  • Network routing failures between your infrastructure and Inngest
  • API gateway overloads causing 5xx errors on event submission

Alert sensitivity: Set to trigger after 1 consecutive failure. When the event API is down, every inngest.send() call in your application fails — no functions fire, no workflows advance.

Step 3: Monitor the Inngest REST API

Beyond event ingestion, the Inngest REST API serves function registration, run management, and event history. CI/CD pipelines use it to sync functions; application code queries it for run status:

curl -I https://api.inngest.com/v1
# Returns HTTP 401 — confirms REST API is reachable
  1. Add Monitor → HTTP.
  2. URL: https://api.inngest.com/v1.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 401.
  6. Label: Inngest REST API.
  7. Click Save.

Step 4: Monitor Your Function Serve Endpoint

This is the most critical monitor for Inngest users. Inngest invokes your application's serve endpoint to execute function steps. If your endpoint is unreachable — because your server is down, the URL changed, or a deployment broke the route — every queued step and retry fails with a connectivity error:

# Your function serve endpoint returns a JSON description for GET requests
curl https://yourapp.com/api/inngest
# Returns: {"message":"Inngest endpoint configured."} or similar introspection response
  1. Add Monitor → HTTP.
  2. URL: https://yourapp.com/api/inngest (replace with your actual serve endpoint).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Inngest (the serve endpoint GET response typically includes "Inngest" in the body).
  7. Label: Inngest serve endpoint.
  8. Click Save.

Framework-specific paths: The Inngest serve endpoint path depends on your framework:

  • Next.js App Router: /api/inngest
  • Next.js Pages Router: /api/inngest
  • Remix: your configured route (e.g., /inngest)
  • SvelteKit: /api/inngest (or your configured path)
  • Express / Fastify: whatever path you registered with serve()

Check your application's serve() configuration for the exact path.

This monitor catches:

  • Application server crashes or container restarts
  • Deployment failures that break the Inngest route
  • Route misconfiguration after framework migrations
  • Load balancer or ingress failures routing to the serve endpoint

Alert sensitivity: Set to trigger after 1 consecutive failure. When your serve endpoint is down, Inngest cannot execute any function steps — including retries of previously-failed runs, scheduled function invocations, and in-progress multi-step workflows.

Step 5: Monitor the Inngest Dashboard

The Inngest dashboard is where engineers inspect function runs, view step-level logs, replay failed events, and manage scheduled functions:

curl -I https://app.inngest.com
# Returns HTTP 200 with Inngest dashboard HTML
  1. Add Monitor → HTTP.
  2. URL: https://app.inngest.com (or your self-hosted Inngest dashboard URL).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Inngest.
  7. Label: Inngest Dashboard.
  8. Click Save.

Self-hosted Inngest: If you run the Inngest open-source server, your dashboard URL will be your internal domain (e.g., https://inngest.internal.example.com). The same monitoring approach applies — Inngest's self-hosted server serves both the API and the dashboard from a single process.

Step 6: Monitor SSL Certificates

Inngest calls your application's serve endpoint over HTTPS to invoke function steps. If your certificate expires, Inngest's servers will fail to connect — functions stop executing, retries fail, and scheduled runs don't fire. Your users see nothing because the failure is in the background:

openssl s_client -connect yourapp.com:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: yourapp.com (the domain hosting your Inngest serve endpoint).
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

This SSL monitor is critical specifically because Inngest calls your server. Unlike end-user HTTPS traffic (where browsers warn users about certificate issues), Inngest's server-to-server calls will fail silently from the user's perspective. The only indication is functions not executing — which may not be noticed for hours or days.

Step 7: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Event API | Non-401/non-200 | inngest.send() calls failing; events not ingested; check Inngest status | | REST API | Non-401/non-200 | Function sync and run management broken; check Inngest status | | Serve endpoint | Non-200 or keyword missing | Inngest cannot invoke your functions; check app server; review deployment | | Dashboard | Non-200 | Engineers can't inspect runs; check Inngest Cloud status or self-hosted server | | SSL certificate | < 30 days to expiry | Renew certificate; Inngest's function calls will fail on expiry |

Alert after: 1 consecutive failure for the event API and serve endpoint monitors. 2 consecutive failures for the REST API and dashboard monitors.

Common Inngest Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Inngest Cloud platform outage | Event API and REST API monitors fire; no functions trigger | | Your serve endpoint crashes | Serve endpoint monitor fires; queued steps fail with connectivity errors | | Deployment breaks the Inngest route | Serve endpoint monitor fires immediately after deploy | | SSL certificate expires on your domain | SSL monitor alerts; Inngest's step invocations fail with TLS errors | | Load balancer misconfiguration | Serve endpoint monitor catches routing failures | | Self-hosted Inngest server crash | Dashboard and API monitors fire; all functions stop | | Database failure in self-hosted Inngest | API may respond; run persistence fails; not directly caught | | Rate limiting on event ingestion | Not caught by availability monitoring; implement SDK-level retry | | DNS failure for your serve endpoint | Serve endpoint monitor fires; Inngest can't resolve your domain | | Function timeout (step takes too long) | Not an uptime issue; configure step timeout in inngest.createFunction |

Monitoring Durable Execution Health

Inngest's durable execution model means that individual steps are retried automatically. However, there are failure modes that don't trigger retries:

  • Step execution timeouts: If a step exceeds its timeout, Inngest retries it — but if your serve endpoint is unreachable, retries can't reach your code. The serve endpoint monitor catches this class of failure.
  • Event fan-out failures: If an event triggers many parallel functions and your serve endpoint is overloaded, some invocations may fail. Inngest's retry logic handles transient failures, but persistent overload requires scaling your serve endpoint.
  • Concurrency limits: If you've set concurrency limits on your functions and all slots are occupied, new runs are queued. This is not an outage — but it can look like one. Monitor queue depth via the Inngest dashboard.

Vigilmon catches infrastructure-level failures: API reachability, serve endpoint availability, dashboard uptime, and SSL expiry. Durable execution health (retry exhaustion, timeout patterns, concurrency saturation) requires Inngest's dashboard and run-level observability.

Inngest is the durable execution layer for every critical background process in your application — the retry-safe, state-managed workflows that run even when servers restart, deployments happen, or steps fail. When Inngest's event API goes down, no functions fire. When your serve endpoint is unreachable, no steps execute. When the dashboard is unavailable, engineers can't diagnose stuck workflows during an incident. Vigilmon gives you external visibility into both sides of the Inngest connection: the platform (event API, REST API, dashboard) and your application (serve endpoint, SSL certificate), so you know the moment either side becomes unavailable and can restore durable function execution before your users notice the gap.

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

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles