tutorial

Monitoring Netflix Conductor with Vigilmon

Netflix Conductor orchestrates long-running workflows across microservices — when the server goes down, in-flight workflows stall silently. Here's how to monitor Conductor's API, health endpoint, and workflow execution with Vigilmon.

Netflix Conductor is a workflow orchestration engine designed for microservices: it coordinates long-running business processes by sequencing tasks across distributed workers. When Conductor goes down, in-flight workflows freeze at their current step with no automatic recovery — and the workers polling for tasks get errors they must handle themselves. Vigilmon gives you an external monitor for Conductor's API server, health endpoint, and workflow execution pipeline, so you catch failures before your orchestrated processes silently stall.

What You'll Set Up

  • HTTP health monitor on Conductor's /health endpoint
  • HTTP monitor on the Conductor REST API
  • TCP port monitor for the Conductor server
  • Cron heartbeat to verify workflow execution is progressing

Prerequisites

  • Netflix Conductor server running (self-hosted or Orkes Cloud)
  • Conductor's REST API accessible over HTTP or HTTPS
  • A free Vigilmon account

Step 1: Monitor the Conductor Health Endpoint

Conductor exposes a health endpoint via the Spring Boot Actuator at /health on its HTTP port (default 8080). This endpoint reports the server status and its connections to Elasticsearch and the backing datastore.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter the URL: http://your-conductor-host:8080/health.
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

Verify the endpoint first:

curl -s http://localhost:8080/health | jq .
# Returns: {"status":"UP","components":{...}}

Conductor's health endpoint returns 200 with {"status":"UP"} when healthy, or 503 when a dependency (Elasticsearch, Redis, database) is unavailable. A 503 indicates Conductor is alive but degraded — workflow scheduling may be impacted even though the process hasn't crashed.

Step 2: Monitor the Conductor REST API

Conductor's core REST API is served at the same port. Add a monitor for the metadata endpoint, which lists registered workflow definitions:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: http://your-conductor-host:8080/api/metadata/workflow.
  3. Set Expected HTTP status to 200.
  4. Set Check interval to 2 minutes.
  5. Click Save.

This confirms that:

  • The REST API layer is responding (not just the actuator)
  • Conductor can read from its backing datastore
  • Workflow definitions are accessible to the engine

If Conductor uses JWT or token authentication, add an X-Authorization header in the monitor configuration with a service account token that has read-only metadata access.

Step 3: Monitor the Conductor UI

Conductor ships with a web UI (served separately, often on port 5000 for the React UI or accessible via the server). Add a monitor for it:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: http://your-conductor-host:5000/ (or the URL of your Conductor UI deployment).
  3. Set Expected HTTP status to 200.
  4. Set Check interval to 5 minutes.
  5. Click Save.

The UI is the interface operators use to inspect and rerun failed workflows — knowing it's down before someone tries to use it during an incident saves critical time.

Step 4: Add a TCP Port Monitor

Add a TCP port monitor as a network-layer check independent of HTTP:

  1. Click Add Monitor → TCP Port.
  2. Enter your Conductor host and port 8080.
  3. Set Check interval to 1 minute.
  4. Click Save.

A TCP failure while the HTTP check is also failing confirms the JVM process has crashed or the network path is broken. If TCP succeeds but HTTP fails, the server is up but the Spring Boot application layer is unresponsive — likely a deadlock or OOM condition in the JVM.

Step 5: Heartbeat Monitoring for Workflow Execution

The health and API checks confirm Conductor is running — they don't confirm workflows are being executed. Use a Vigilmon cron heartbeat wired into a lightweight test workflow to verify end-to-end orchestration.

Create a minimal "canary" workflow definition in Conductor:

{
  "name": "vigilmon_canary",
  "description": "Canary workflow that pings Vigilmon heartbeat",
  "version": 1,
  "tasks": [
    {
      "name": "ping_vigilmon",
      "taskReferenceName": "ping_vigilmon_ref",
      "type": "HTTP",
      "inputParameters": {
        "http_request": {
          "uri": "https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID",
          "method": "GET",
          "connectionTimeOut": 5000,
          "readTimeOut": 5000
        }
      }
    }
  ],
  "outputParameters": {},
  "schemaVersion": 2,
  "restartable": true,
  "workflowStatusListenerEnabled": false
}

Register this workflow, then schedule it to run every 5 minutes using an external scheduler (cron job, Conductor's own scheduler extension, or a simple script):

# Trigger the canary workflow via the API every 5 minutes
*/5 * * * * curl -s -X POST http://your-conductor-host:8080/api/workflow/vigilmon_canary \
  -H "Content-Type: application/json" \
  -d '{"name":"vigilmon_canary","version":1,"input":{}}'

In Vigilmon:

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected interval to 5 minutes.
  3. Copy the heartbeat URL into the workflow definition above.
  4. Click Save.

If Conductor stops executing workflows — due to an Elasticsearch connectivity issue, a task queue problem, or JVM memory pressure — the canary workflow stalls and the heartbeat ping stops. Vigilmon alerts within 10 minutes.

Step 6: Monitor Elasticsearch Availability

Conductor uses Elasticsearch (or OpenSearch) for workflow indexing and search. Elasticsearch degradation causes workflow search to fail and can eventually impact scheduling. Add a monitor for it:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: http://your-elasticsearch-host:9200/_cluster/health.
  3. Set Expected HTTP status to 200.
  4. Optionally set Response body must contain to "green" or "yellow" to catch red cluster status.
  5. Click Save.

A red Elasticsearch cluster while Conductor's own health endpoint returns 200 creates a split state that's hard to diagnose — this monitor surfaces it independently.

Step 7: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
  2. Set Consecutive failures before alert to 2 on HTTP monitors — Conductor's Spring Boot startup and GC pauses can cause brief probe failures.
  3. Route Conductor alerts to the same channel as your application's on-call alerts, since a Conductor outage stalls application-level business processes.
  4. Add Maintenance windows during Conductor version upgrades to suppress false positives during the rolling restart window.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP health | :8080/health | Process crash, dependency failure | | HTTP metadata API | :8080/api/metadata/workflow | API layer failure, datastore loss | | HTTP web UI | :5000/ | UI unavailability | | TCP port | :8080 | Network/JVM crash | | HTTP Elasticsearch | :9200/_cluster/health | Search index degradation | | Cron heartbeat | Heartbeat URL | Workflow execution halt |

Netflix Conductor coordinates the business processes that span your entire microservice fleet — a silent failure here freezes transactions, order fulfillment, and data pipelines without a single error appearing in any individual service. With Vigilmon monitoring the health endpoint, REST API, Elasticsearch, and a canary workflow heartbeat, you get an external vantage point that catches Conductor failures before they cascade into stalled business logic across your stack.

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