Monitoring Self-Hosted FeatBit with Vigilmon

FeatBit gives you fully self-hosted feature flags and A/B testing without sending flag evaluations to a third-party cloud. That privacy comes with an operational responsibility: when your FeatBit server goes down, every application relying on it for flag evaluation falls back to defaults — silently, with no indication of the outage. Vigilmon keeps continuous watch on your FeatBit instance so you catch degradations before they cause unexpected feature rollouts or stuck experiments.

What You'll Set Up

• HTTP health monitor for the FeatBit API service on port 5000
• Streaming connection endpoint probe for real-time flag delivery
• SDK integration health check via the evaluation API
• FeatBit dashboard (web UI) availability monitoring
• Alerting with alert channel configuration

Prerequisites

• FeatBit self-hosted (Docker Compose or Kubernetes)
• FeatBit API accessible on port 5000 (default)
• A free Vigilmon account

Step 1: Monitor the FeatBit API Health Endpoint

FeatBit's API service exposes a /api/public/health endpoint for liveness checks.

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

When the API service is healthy, this endpoint returns a 200 with a simple healthy body. If the service is starting up, restarting after a crash, or has lost its database connection, the endpoint returns a non-200 status or times out.

Step 2: Monitor Streaming Connection Availability

FeatBit delivers real-time flag updates to connected SDKs over a streaming endpoint. If the streaming service degrades, applications continue running with stale flag values — sometimes indefinitely. Probe the streaming endpoint directly:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: http://your-featbit-host:5000/streaming
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200 or 101 (WebSocket upgrade response).
5. Click Save.

The streaming endpoint serves both HTTP long-polling and WebSocket connections. A 200 response confirms the streaming service is accepting connections. A 502 or timeout indicates the streaming layer has failed even if the REST API appears healthy.

Step 3: Probe the SDK Evaluation API

The evaluation API is the path your SDKs use to fetch flag values. Monitor it separately from the management API to distinguish user-facing degradations from admin-only problems:

1. Click Add Monitor → HTTP / HTTPS.

2. Enter: http://your-featbit-host:5000/api/public/sdk/server/latest-all

   Replace server with client if you're primarily using browser SDKs.

3. Set Check interval to 2 minutes.

4. Set Expected HTTP status to 401.

   This endpoint requires authentication, so a 401 confirms it's reachable and processing requests. A 500 or timeout is the failure condition you're detecting.

5. Click Save.

Monitoring for the expected 401 (rather than 200) is a valid technique for protected endpoints — it proves the service is running and responding, not that the caller has valid credentials.

Step 4: Monitor the FeatBit Web Dashboard

The FeatBit web UI typically runs on a separate port or subdomain. If the dashboard becomes unavailable, feature flag management is blocked for your entire team.

1. Click Add Monitor → HTTP / HTTPS.
2. Enter the FeatBit web UI URL: http://your-featbit-host:8081 (default UI port, adjust if changed).
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Under Keyword match, enter FeatBit to verify the correct application is being served.
6. Click Save.

Step 5: Monitor the Message Queue (Redis)

FeatBit uses Redis for caching flag state and coordinating between services. A Redis failure causes the streaming service to return stale data without surfacing a clear error. If your Redis instance is on the same host as FeatBit, add a TCP port monitor:

1. Click Add Monitor → TCP Port.
2. Enter Host: your-featbit-host
3. Enter Port: 6379 (default Redis port)
4. Set Check interval to 2 minutes.
5. Click Save.

A TCP monitor confirms Redis is accepting connections. Pair this with the API health check — if API health is green but Redis TCP is failing, you know flag evaluations are running on stale cached data.

Step 6: Configure Alerting

Add an alert channel

1. Go to Alert Channels in Vigilmon.
2. Add Slack, email, or a webhook.
3. Assign the channel to each FeatBit monitor.

Alert threshold tuning

FeatBit containers can take 10–15 seconds to restart after a crash. Set Consecutive failures before alert to 2 on the API health and streaming monitors to avoid alerting during brief restarts.

Maintenance windows during FeatBit upgrades

FeatBit uses database migrations during version upgrades. Suppress monitoring alerts while migrations run:

# Open maintenance window before upgrading
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "monitor_id": "featbit-api-monitor-id",
    "duration_minutes": 15
  }'

# Pull new images and recreate containers
docker compose pull
docker compose up -d

# Verify migration completed
docker compose logs api | grep "migration"

Summary

| Monitor | Target | What It Catches | |---|---|---| | API health | :5000/api/public/health | Service crash, startup failure | | Streaming endpoint | :5000/streaming | Real-time delivery failure | | SDK evaluation API | :5000/api/public/sdk/... | Flag evaluation path broken | | Web dashboard | :8081 | UI unavailable for team | | Redis TCP | :6379 | Cache/queue connectivity loss |

FeatBit's self-hosted model means your flag evaluation never leaves your infrastructure — but it also means your infrastructure is the availability story. With Vigilmon watching the API, streaming layer, evaluation endpoint, and Redis backend, you'll know about FeatBit problems before they silently affect feature rollouts across your applications.