OpenFeature Monitoring with Vigilmon

OpenFeature is the CNCF-backed open standard for feature flagging. It defines a vendor-neutral SDK that connects your application to any feature flag backend — LaunchDarkly, Flagd, GrowthBook, ConfigCat, and others. When the OpenFeature provider goes down or can't reach its upstream flag source, your application may fall back to defaults silently, or worse, throw exceptions on every flag evaluation.

This guide covers how to monitor OpenFeature-powered services and their flag providers with Vigilmon.

What Can Go Wrong with OpenFeature

Feature flag systems fail in subtle ways:

• Provider connection drops — the SDK can't reach the remote flag backend; evaluations silently return defaults
• Stale flag cache — the in-process cache stops refreshing; you're evaluating yesterday's flags
• SDK initialization failure — the provider never completes READY state; the SDK is in NOT_READY and all evaluations return defaults
• Streaming disconnect — SSE or WebSocket connections to flagd or a SaaS provider drop; flag changes stop propagating

OpenFeature itself doesn't expose a single health endpoint — monitoring must happen at two layers: the application exposing its feature flag status, and the provider backend (flagd, GrowthBook, etc.) being reachable.

Exposing a Feature Flag Health Endpoint

The simplest approach is adding a health route to your application that reports OpenFeature SDK state.

Node.js / Express example

import { OpenFeature, ProviderStatus } from '@openfeature/server-sdk';
import express from 'express';

const app = express();

app.get('/health/flags', (req, res) => {
  const provider = OpenFeature.getProvider();
  const status = provider.status;

  const healthy = status === ProviderStatus.READY;
  res.status(healthy ? 200 : 503).json({
    status: healthy ? 'ok' : 'degraded',
    providerStatus: status,
    providerName: provider.metadata.name,
  });
});

Go example

import (
    "encoding/json"
    "net/http"
    "go.openfeature.dev/sdk"
)

func flagHealthHandler(w http.ResponseWriter, r *http.Request) {
    provider := openfeature.GetProvider()
    state := provider.Status()

    healthy := state == openfeature.ReadyState
    status := map[string]interface{}{
        "status":         "ok",
        "providerStatus": state.String(),
    }
    if !healthy {
        w.WriteHeader(http.StatusServiceUnavailable)
        status["status"] = "degraded"
    }
    json.NewEncoder(w).Encode(status)
}

A healthy response looks like:

{
  "status": "ok",
  "providerStatus": "READY",
  "providerName": "flagd-provider"
}

Monitoring Flagd (OpenFeature's Reference Provider)

If you run flagd as your provider, it exposes its own health and sync endpoints.

Flagd default ports:

• 8013 — gRPC flag evaluation
• 8014 — metrics and health (HTTP)

# Flagd liveness
curl http://localhost:8014/healthz

# Flagd readiness (provider is synced and ready)
curl http://localhost:8014/readyz

Both return 200 OK with body {"status":"ok"} when healthy.

Vigilmon Monitor Configuration

Monitor 1: Application Feature Flag Health

1. Log in to Vigilmon → Monitors → New Monitor
2. Type: HTTP
3. Method: GET
4. URL: https://your-app.example.com/health/flags
5. Interval: 1 minute
6. Expected status code: 200
7. Keyword check: "status":"ok"
8. Save

This catches provider connection drops, SDK initialization failures, and any state outside READY.

Monitor 2: Flagd Readiness

1. Type: HTTP
2. Method: GET
3. URL: http://flagd.internal:8014/readyz
4. Interval: 1 minute
5. Expected status code: 200
6. Keyword check: ok
7. Save

Monitor 3: Remote Flag Provider API Reachability

If your provider is a SaaS (e.g., LaunchDarkly, Unleash, ConfigCat), monitor their API directly:

1. Type: HTTP
2. Method: GET
3. URL: https://sdk.launchdarkly.com (replace with your provider's SDK endpoint)
4. Interval: 2 minutes
5. Expected status code: any 2xx
6. Save

This gives you independent confirmation when a third-party provider has an incident.

Key Metrics to Watch

| Metric | What it means | Healthy threshold | |--------|--------------|-------------------| | Provider status | SDK is READY | Always READY | | /readyz response | Flagd synced from source | 200 OK | | Flag evaluation latency | Time to resolve a flag | < 5 ms (in-process cache) | | Provider reconnect count | How often the SDK reconnects | Ideally 0 per hour | | Stale cache age | Time since last flag sync | < 60 seconds |

Alerting Recommendations

Critical alerts (page immediately):

• Application /health/flags returns non-200 — provider is not READY
• Flagd /readyz returns non-200 — sync is broken

Warning alerts (notify, don't page):

• Remote provider API unreachable for > 2 minutes — upstream incident likely
• Flag evaluation p99 latency exceeds 50 ms — cache miss or remote call on every evaluation

Suggested Vigilmon alert settings:

• Confirmation: 2 consecutive failures before alerting (avoids flapping)
• Recovery: 2 consecutive successes before resolving
• Notification channels: email for warnings, SMS/Slack for critical

Testing Your Monitors

Simulate a provider failure to confirm alerts fire:

# Stop flagd to trigger a provider connection failure
docker stop flagd

# Verify your health endpoint now returns 503
curl -i https://your-app.example.com/health/flags
# HTTP/1.1 503 Service Unavailable
# {"status":"degraded","providerStatus":"ERROR"}

Vigilmon should alert within 1–2 minutes. Restart flagd to confirm recovery notification.

Summary

OpenFeature monitoring requires watching two layers: the application's SDK state and the provider backend. With Vigilmon you can track both with HTTP monitors — catching silent fallbacks before they affect users. The key signal is the provider's READY status; anything else means your flags are stale or defaulting.

Set up monitors at vigilmon.online and get alerted the moment your feature flag infrastructure goes down.