Monitoring Flagsmith with Vigilmon

Flagsmith is the open-source feature flag and remote configuration service that lets teams roll out features gradually, run A/B tests, and change application behavior at runtime without redeploying code. Every SDK client — whether in a mobile app, backend service, or browser — polls Flagsmith's API to retrieve the current state of feature flags and remote config values. If Flagsmith is unavailable, SDK clients fall back to locally cached state, and any flags that were off when the cache was last populated will remain off — silently blocking features that should have been live. Vigilmon gives you the external monitoring layer to detect Flagsmith API failures, Edge API degradation, and infrastructure health issues before they affect your feature delivery pipeline.

What You'll Set Up

• HTTP monitor for the Flagsmith API health endpoint
• Feature flag evaluation endpoint check
• Edge API availability monitoring (if using Flagsmith Edge)
• Admin dashboard UI monitoring
• SSL certificate expiry monitoring and alert configuration

Prerequisites

• Flagsmith deployed self-hosted (Docker, Kubernetes via Helm chart, or bare metal) or using Flagsmith Cloud
• The Flagsmith API accessible at a stable URL (e.g. https://flagsmith.example.com)
• A valid Flagsmith Environment API key (from your Project Settings)
• A free Vigilmon account

Step 1: Monitor the Flagsmith API Health Endpoint

Flagsmith exposes a health check endpoint that confirms the API server is running and can reach its database:

GET https://flagsmith.example.com/health

A healthy Flagsmith instance returns HTTP 200 with:

{
  "status": "ok"
}

Configure Vigilmon:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter URL: https://flagsmith.example.com/health.
4. Set Expected HTTP status to 200.
5. Set Expected body contains to ok.
6. Set Check interval to 1 minute.
7. Click Save.

This is the most critical Flagsmith monitor. A 500 or a body other than "status": "ok" indicates the API server cannot reach PostgreSQL or Redis — all SDK evaluations will be serving stale cached data from the last successful poll.

Step 2: Monitor the Feature Flag Evaluation API

The Flagsmith SDK evaluation endpoint is what every SDK client calls to retrieve the list of feature flags and remote config values for a given environment:

GET https://flagsmith.example.com/api/v1/flags/
X-Environment-Key: <your-environment-api-key>

A healthy response returns HTTP 200 with a JSON array of flag objects:

[
  {
    "id": 1,
    "feature": { "id": 42, "name": "dark_mode", "type": "FLAG" },
    "enabled": true,
    "feature_state_value": null
  }
]

Configure Vigilmon:

1. Add Monitor → HTTP / HTTPS.
2. URL: https://flagsmith.example.com/api/v1/flags/.
3. In Custom headers, add X-Environment-Key: <your-environment-api-key>.
4. Set Expected HTTP status to 200.
5. Set Expected body contains to "feature".
6. Set Check interval to 2 minutes.
7. Click Save.

This check exercises the full evaluation path — including database reads, environment hydration, and flag serialization. If this check fails while /health returns ok, the issue is in the API routing or the flags serialization layer, not the database connection.

Step 3: Monitor the Identities Endpoint

Flagsmith's most powerful feature is per-identity flag overrides — individual users or devices can have different flag values based on identity traits. The identities endpoint is what SDK clients call when initializing with a user ID:

POST https://flagsmith.example.com/api/v1/identities/
X-Environment-Key: <your-environment-api-key>
Content-Type: application/json

{"identifier": "monitoring-probe"}

A healthy response returns HTTP 200 with both flags and traits for the given identity. Vigilmon cannot easily POST a request body, so use a GET check on the identity endpoint with a known probe identity to confirm the endpoint is accepting requests:

GET https://flagsmith.example.com/api/v1/identities/?identifier=monitoring-probe
X-Environment-Key: <your-environment-api-key>

Configure Vigilmon:

1. Add Monitor → HTTP / HTTPS.
2. URL: https://flagsmith.example.com/api/v1/identities/?identifier=monitoring-probe.
3. In Custom headers, add X-Environment-Key: <your-environment-api-key>.
4. Set Expected HTTP status to 200.
5. Set Expected body contains to "flags".
6. Set Check interval to 5 minutes.
7. Click Save.

An identity named monitoring-probe will be created in Flagsmith on first call and will use the default environment flag values. This is expected behavior — the probe identity is intentional and can be reviewed in the admin dashboard.

Step 4: Monitor the Edge API (If Using Flagsmith Edge)

Flagsmith Edge is a globally distributed, low-latency flag evaluation layer that caches flag state at CDN edge nodes. SDK clients that point at the Edge API get sub-millisecond flag evaluation without hitting your self-hosted Flagsmith API server. If the Edge API is down, SDK clients that rely on it lose flag evaluation entirely.

Flagsmith Edge exposes a health endpoint:

GET https://edge.api.flagsmith.com/api/v1/health/

Or for self-hosted Edge instances:

GET https://edge.flagsmith.example.com/api/v1/health/

Configure Vigilmon:

1. Add Monitor → HTTP / HTTPS.
2. URL: https://edge.api.flagsmith.com/api/v1/health/ (or your self-hosted edge URL).
3. Set Expected HTTP status to 200.
4. Set Expected body contains to ok.
5. Set Check interval to 1 minute.
6. Click Save.

Add a second monitor for the Edge flags evaluation endpoint to confirm it's serving flag data correctly:

GET https://edge.api.flagsmith.com/api/v1/flags/
X-Environment-Key: <your-environment-api-key>

Set Expected body contains to "feature" and Check interval to 2 minutes.

Step 5: Monitor the Admin Dashboard

The Flagsmith admin dashboard is the web UI where product managers and engineers manage feature flags, configure segments, and control rollout percentages. While the UI going down doesn't affect SDK flag evaluation, it prevents the team from modifying flags during an incident — exactly when you need to quickly disable a broken feature.

GET https://flagsmith.example.com

Configure Vigilmon:

1. Add Monitor → HTTP / HTTPS.
2. URL: https://flagsmith.example.com.
3. Set Expected HTTP status to 200.
4. Set Expected body contains to Flagsmith (or another unique string from the login page HTML).
5. Set Check interval to 5 minutes.
6. Click Save.

In self-hosted deployments, the frontend dashboard and the API backend are typically separate Docker containers — the API can be healthy while the frontend container is down, or vice versa. Separate monitors for the API (/health) and the UI root (/) let you distinguish these failure modes.

Step 6: Monitor the Prometheus Metrics Endpoint (Self-Hosted)

Flagsmith's self-hosted API server optionally exposes a Prometheus metrics endpoint:

GET https://flagsmith.example.com/prometheus/

This endpoint exposes request counts, database query latencies, cache hit rates, and error rates. You can configure a Vigilmon HTTP monitor to confirm the metrics endpoint is reachable:

1. Add Monitor → HTTP / HTTPS.
2. URL: https://flagsmith.example.com/prometheus/.
3. Set Expected HTTP status to 200.
4. Set Expected body contains to # HELP (standard Prometheus metrics text format header).
5. Set Check interval to 5 minutes.
6. Click Save.

Pairing Vigilmon's external uptime monitoring with internal Prometheus metrics scraped by Grafana gives you two complementary visibility layers: Vigilmon tells you the API is reachable from outside, while Prometheus tells you how it's performing from the inside.

Step 7: SSL Certificate Monitoring and Alert Configuration

Add SSL expiry monitoring for Flagsmith's API and UI endpoints:

1. Add Monitor → SSL Certificate.
2. URL: https://flagsmith.example.com.
3. Set Alert when certificate expires in less than 30 days.
4. Click Save.

If you use the Flagsmith Edge API on a separate domain, add SSL monitoring for that as well.

Configure alert channels:

1. Go to Alert Channels → add Slack, PagerDuty, or email.
2. For the /health endpoint: Consecutive failures before alert = 1 — a failed health check means the database is unreachable and SDK clients are serving stale cached flags.
3. For the flags evaluation endpoint (/api/v1/flags/): 1 consecutive failure — this is the primary SDK client endpoint.
4. For the Edge API: 2 consecutive failures — brief CDN cache misses during deployments are normal.
5. For the admin UI and Prometheus metrics: 3 consecutive failures — these are non-critical to SDK evaluation.
6. Add Maintenance windows for Flagsmith version upgrades and PostgreSQL migrations, which can take Flagsmith offline for up to 2 minutes.

Going Further

• PostgreSQL health monitoring: Flagsmith stores all flag state in PostgreSQL. Add a separate Vigilmon TCP monitor on port 5432 (or your PostgreSQL port) to detect database host failures independently from Flagsmith API failures. A failed database with a healthy Flagsmith API process explains a failing /health check instantly.
• Redis connectivity: Flagsmith uses Redis as a write-through cache and for analytics event buffering. Monitor your Redis instance's health endpoint or TCP port 6379 separately to distinguish Redis failures from database failures in your alert routing.
• Webhook delivery monitoring: Flagsmith can send webhook events to external systems when flags change. Add a small receiver service that accepts Flagsmith webhooks and exposes a /last-received timestamp endpoint, then add a Vigilmon monitor to confirm webhooks are being delivered within your expected interval.
• Segment evaluation correctness: Create a dedicated monitoring environment in Flagsmith with a test identity that matches a known segment. Poll the identities endpoint for that test identity and verify the expected flags are enabled — this is an end-to-end correctness check that goes beyond simple API availability.
• Multi-region deployments: If you self-host Flagsmith across multiple regions, add Vigilmon monitors from multiple probe locations for each region's API endpoint. A region-local Flagsmith failure that only affects users in that geography will only show up in Vigilmon if you have monitoring probes in that region.

With Vigilmon monitoring Flagsmith's health endpoint, flag evaluation API, Edge API, admin UI, and infrastructure dependencies, you have full external visibility into your feature flag delivery pipeline — ensuring that any failure is caught before it silently degrades your feature rollouts or forces SDK clients to serve stale flag state.