Keploy Monitoring with Vigilmon: Server Uptime, Test Execution & Traffic Capture Health Checks

Your Keploy traffic capture pipeline stopped recording for eighteen hours. Every API call your application made during that window — the test cases that would have caught the regression shipped in the next deploy — was lost. Nobody noticed because the Keploy server appeared to be running. The capture daemon had silently exited after an out-of-memory event, and the test suite generation queue had been empty ever since.

Keploy is an open-source API testing and mocking platform that automatically generates test cases from real traffic. It runs a Go server on port 6789, captures live API traffic through an eBPF-based proxy, stores the recorded interactions, and replays them as automated tests with auto-generated mocks. Self-hosting Keploy gives your team zero-effort test generation — as long as the capture pipeline, the server, and the storage backend are all running.

Vigilmon monitors your Keploy instance from outside, the way a CI system or a developer would. If the server becomes unreachable, if the traffic capture daemon exits, or if the test execution service fails, Vigilmon alerts your team before the next deploy ships without adequate test coverage.

What You'll Build

• An HTTP monitor on the Keploy server process
• A test execution service health check
• A traffic capture pipeline monitor
• A mock generation API probe
• A database connectivity check
• A test suite completion monitor
• Alert channels for your testing infrastructure team

Prerequisites

• A self-hosted Keploy installation (v2.x recommended)
• Default port: 6789
• A free account at vigilmon.online

Step 1: Monitor the Keploy Server Process

Keploy's server exposes its REST API on port 6789. If the Go process crashes or the port becomes unavailable, all capture and replay operations halt immediately. This is the highest-priority monitor to set up.

Test the server health endpoint:

curl -s http://your-keploy-host:6789/healthz

Expected response:

{"status": "ok"}

A connection refused response means the Go process has exited. A timeout means the server is alive but unresponsive — often caused by a goroutine deadlock.

Set up the Vigilmon monitor:

1. Log in to Vigilmon and click New Monitor → HTTP.
2. Set URL to http://your-keploy-host:6789/healthz.
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Under Advanced → Keyword check, add:
   • Keyword present: ok
6. Save the monitor.

This is your first line of defense — if this monitor fires, every other Keploy function is also broken.

Step 2: Monitor the Test Execution Service

Keploy's test runner replays recorded test cases against your application and validates the responses against stored mocks. If the test execution service is broken, CI pipeline runs will hang or return false-positive results. Check the test execution API:

curl -s http://your-keploy-host:6789/api/regression/testrun \
  -H "Content-Type: application/json"

Expected: a 200 response listing test run history, or an empty array if no runs exist yet. A 500 or 503 indicates the test execution backend is unhealthy.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-keploy-host:6789/api/regression/testrun.
3. Set Expected status code to 200.
4. Set Check interval to 120 seconds.
5. Save the monitor.

Step 3: Monitor the Traffic Capture Pipeline

The traffic capture pipeline is the core feature of Keploy — it intercepts real API traffic via eBPF hooks and records interactions for test generation. If the capture daemon exits or the eBPF hooks fail to attach, the pipeline silently stops recording. No error surfaces; the system appears healthy until you notice that no new test cases have been generated.

Probe the capture pipeline status through the apps API:

curl -s http://your-keploy-host:6789/api/app

Expected: a JSON response listing registered apps and their capture status. A healthy capture pipeline shows apps with recent activity timestamps. A crashed daemon results in stale timestamps or a 500 error from the backend.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-keploy-host:6789/api/app.
3. Set Expected status code to 200.
4. Set Check interval to 120 seconds.
5. Save the monitor.

For deeper monitoring, expose a custom endpoint from your Keploy configuration that checks whether the eBPF capture hook is active and returns a 503 if it is not. Point Vigilmon at that endpoint with a keyword check on "capturing":true.

Step 4: Monitor the Mock Generation API

Keploy auto-generates mocks from captured traffic so test replays don't need live external services. If the mock generation API fails, test cases run without mocks and hit real external dependencies — breaking your test isolation and potentially sending unwanted requests to production APIs.

Test the mock API endpoint:

curl -s http://your-keploy-host:6789/api/mock

Expected: a 200 response with a JSON array of stored mocks (may be empty on a fresh install). A non-200 response or a 500 error indicates the mock storage layer is broken.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-keploy-host:6789/api/mock.
3. Set Expected status code to 200.
4. Set Check interval to 180 seconds.
5. Save the monitor.

Step 5: Monitor Database Connectivity

Keploy stores captured test cases, mocks, and test run results in a database (MongoDB or a file-based store, depending on your configuration). If the database becomes unreachable, new captures cannot be saved and existing test cases cannot be retrieved for replay.

Probe database connectivity through the test cases API:

curl -s "http://your-keploy-host:6789/api/regression/testcase?app=your-app-name&limit=1"

Expected: a 200 with a JSON response (empty array if no test cases exist). A 500 or a JSON body containing an error message about database connectivity indicates the storage backend is down.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-keploy-host:6789/api/regression/testcase?app=your-app-name&limit=1.
3. Set Expected status code to 200.
4. Under Advanced → Keyword check, add:
   • Keyword absent: error
5. Set Check interval to 120 seconds.
6. Save the monitor.

Step 6: Monitor Test Suite Completion

Test suite runs triggered by CI pipelines should complete within a predictable time window. A hung test run (caused by a network timeout, an unresponsive mock, or a deadlocked goroutine in the test runner) blocks your CI pipeline and delays deployments. Monitor the test run result API to detect hung or failed runs:

curl -s "http://your-keploy-host:6789/api/regression/testrun?app=your-app-name&limit=5"

Parse the response to check whether recent runs have a status of completed or failed. A run stuck in running state for more than your expected run time indicates a hung test runner.

For a simpler external monitor, create a lightweight CI wrapper script that POSTs the test run result to a Vigilmon-compatible webhook when the suite completes successfully. Configure a Vigilmon cron/heartbeat monitor that expects a ping at least once per CI run:

1. Click New Monitor → Heartbeat in Vigilmon.
2. Set the expected ping interval to match your CI schedule (e.g., every 60 minutes for an hourly pipeline).
3. Copy the heartbeat ping URL.
4. In your CI script, add curl -s YOUR_HEARTBEAT_URL after a successful Keploy test run.
5. Save the monitor.

Vigilmon alerts if the ping doesn't arrive within the expected window — meaning either the CI pipeline failed to run or Keploy's test execution never completed.

Step 7: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

• Email — immediate alerts to your platform engineering or QA team
• Webhook — Slack or Discord for CI pipeline visibility

A failing server process alert in Slack looks like:

🔴 DOWN: keploy-server (HTTP monitor)
Expected status 200 on /healthz, got connection refused
Region: US-East
Triggered: 2026-07-02 01:58 UTC

When the server recovers:

✅ RECOVERED: keploy-server
Downtime: 12 minutes

A missed heartbeat from the CI test suite:

🔴 MISSED: keploy-ci-heartbeat (Heartbeat monitor)
Expected ping within 60 minutes, none received
Last ping: 2026-07-02 00:47 UTC

Set critical severity for the server health and database connectivity monitors. Use warning severity for the traffic capture pipeline and test suite heartbeat monitors. Enable Alerting → Escalation for the server health monitor — a down Keploy server means your team is shipping code without auto-generated test coverage.

What You've Built

| Scenario | How Vigilmon catches it | |---|---| | Keploy Go process crash | /healthz monitor returns connection refused | | Test execution backend failure | /api/regression/testrun returns 500 | | eBPF capture daemon exit | App API shows stale capture timestamps or returns error | | Mock generation storage broken | /api/mock returns non-200 | | Database host unreachable | Test case API returns 500 or error keyword | | Hung test suite run blocking CI | Heartbeat monitor misses expected ping | | goroutine deadlock in test runner | Server health monitor times out (no response) |

Automated test generation only protects you if the capture pipeline actually ran. External monitoring with Vigilmon gives you a real-time signal when Keploy's server, traffic capture, or test execution layer fails — before the next deploy ships with a gap in your test coverage you didn't know existed.

Start monitoring your Keploy server today — register free at vigilmon.online.