GrowthBook Monitoring with Vigilmon

GrowthBook is an open-source feature flagging and A/B testing platform. It lets you run experiments, roll out features gradually, and analyze results using your own data warehouse. When GrowthBook goes down, feature flags fail to evaluate and A/B test assignments stop working — users get fallback behavior and experiment data disappears.

This guide covers how to monitor GrowthBook with Vigilmon.

GrowthBook's Architecture

GrowthBook has two deployment modes:

Cloud (app.growthbook.io)

• GrowthBook manages the API and UI
• You connect your data warehouse for analysis
• Monitoring focuses on SDK data file reachability and event endpoint

Self-hosted (Docker/Kubernetes)

• You run the GrowthBook app server (Node.js) and MongoDB
• Port 3000 is the web UI/API
• Port 3100 is the SDK proxy (optional but recommended for production)

GrowthBook Health Endpoints

Self-hosted GrowthBook app

# App server liveness
GET http://localhost:3000/healthcheck

# Returns:
# {"status": "ok"}

GrowthBook SDK Proxy

The SDK proxy caches the features JSON and serves it to your SDKs. It's critical for production — without it, every SDK initialization hits the GrowthBook API directly.

# Proxy health
GET http://localhost:3100/healthcheck

# Returns 200 OK when the proxy is running and can reach GrowthBook

Features endpoint (the most important one)

The features JSON file is what your SDKs download to evaluate flags:

# Your features endpoint (client key varies)
GET https://cdn.growthbook.io/api/features/sdk-abc123

# Or self-hosted:
GET https://growthbook.example.com/api/features/sdk-abc123

A valid response includes:

{
  "status": 200,
  "features": {
    "my-feature": {
      "defaultValue": false,
      "rules": [...]
    }
  },
  "dateUpdated": "2024-01-15T10:00:00Z"
}

Vigilmon Monitor Configuration

Monitor 1: GrowthBook App Health (self-hosted)

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

Monitor 2: SDK Features Endpoint

This is the most critical monitor — it checks that SDKs can download your feature definitions:

1. Type: HTTP
2. Method: GET
3. URL: https://growthbook.example.com/api/features/YOUR_CLIENT_KEY
4. Interval: 1 minute
5. Expected status code: 200
6. Keyword check: "features"
7. Save

For cloud users, use https://cdn.growthbook.io/api/features/YOUR_CLIENT_KEY.

Monitor 3: SDK Proxy (if deployed)

1. Type: HTTP
2. Method: GET
3. URL: http://growthbook-proxy.internal:3100/healthcheck
4. Interval: 1 minute
5. Expected status code: 200
6. Save

Monitor 4: GrowthBook Event Tracking

GrowthBook ingests experiment events via its tracking endpoint. A failure here means experiment data is being lost:

# Test the ingest endpoint manually
curl -X POST https://growthbook.example.com/api/v1/experiment-results \
  -H "Authorization: Bearer YOUR_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ping": true}'

Add an HTTP monitor for POST https://growthbook.example.com/api/v1/experiment-results with your authorization header and expect a 200/400 response (not 5xx).

Key Metrics to Watch

| Metric | What it means | Healthy threshold | |--------|--------------|-------------------| | /healthcheck status | App server is running | 200 OK always | | Features endpoint latency | SDK initialization speed | < 200 ms | | Features dateUpdated freshness | Rules are current | < 1 hour old | | SDK proxy cache hit rate | Proxy is serving from cache | > 95% | | MongoDB connectivity | Database is reachable | Always connected |

Monitoring features freshness

If your features haven't updated in a long time, flag evaluations may be stale. Add a monitoring script that checks dateUpdated:

#!/bin/bash
FEATURES=$(curl -s https://growthbook.example.com/api/features/YOUR_KEY)
DATE_UPDATED=$(echo $FEATURES | jq -r '.dateUpdated')
AGE_SECONDS=$(( $(date +%s) - $(date -d "$DATE_UPDATED" +%s) ))

if [ $AGE_SECONDS -gt 3600 ]; then
  echo "WARN: features not updated in ${AGE_SECONDS}s"
  exit 1
fi
echo "OK: features updated ${AGE_SECONDS}s ago"

Alerting Recommendations

Critical alerts (page immediately):

• /healthcheck non-200 — GrowthBook server is down
• Features endpoint non-200 — SDKs can't initialize; all flags default
• SDK proxy down — every SDK init hits the origin directly (overload risk)

Warning alerts (notify, don't page):

• Features endpoint latency > 500 ms — SDKs are slow to start
• Features dateUpdated > 1 hour old — flag configuration may be stale
• GrowthBook UI unreachable — team can't manage flags (not user-facing but operationally critical)

Suggested Vigilmon alert settings:

• Confirmation: 2 consecutive failures
• Recovery: 2 consecutive successes
• Channels: Slack for warnings, email + SMS for critical

MongoDB Monitoring for Self-Hosted GrowthBook

GrowthBook stores all feature flag configuration in MongoDB. A MongoDB outage takes down the entire platform.

Add a TCP port monitor for your MongoDB instance:

1. Type: TCP
2. Host: mongo.internal
3. Port: 27017
4. Interval: 1 minute
5. Save

If MongoDB becomes unreachable, Vigilmon alerts you before GrowthBook itself starts failing requests.

Testing Your Monitors

To validate the monitors fire correctly, you can temporarily take GrowthBook down:

# Self-hosted: stop the container
docker stop growthbook

# Vigilmon should alert within 1–2 minutes

# Bring it back
docker start growthbook

# Vigilmon should send a recovery notification

Summary

GrowthBook monitoring has two layers: the platform infrastructure (app server, MongoDB, SDK proxy) and the features endpoint that SDKs depend on. The features endpoint is your most critical monitor — if it's unreachable, every application using GrowthBook falls back to default flag values immediately.

Set up monitors at vigilmon.online and get alerted before a GrowthBook outage affects your experiments or feature rollouts.