tutorial

Monitoring Testkube with Vigilmon: API Health, Dashboard Availability, Test Execution Endpoint & SSL Certificate Alerts

How to monitor Testkube with Vigilmon — API health checks, dashboard availability, test execution endpoint monitoring, and SSL certificate alerts for cloud-native Kubernetes testing.

Testkube is the cloud-native Kubernetes testing framework that runs test suites natively inside your cluster — executing Playwright tests, k6 load tests, Postman collections, Artillery scripts, and custom executors as Kubernetes Jobs, with results stored and accessible through a centralized API and dashboard. When Testkube's API server becomes unavailable, CI/CD pipelines that trigger test runs via the testkube CLI or REST API fail silently, leaving engineers with no confirmation that their Kubernetes workloads are behaving correctly after a deployment. When the test execution endpoint is unreachable, scheduled and on-demand test runs stop initiating. Vigilmon gives you external visibility into Testkube's availability: the API health endpoint, dashboard UI, test execution REST API, and SSL certificate expiry.

What You'll Build

  • A monitor on Testkube's API health endpoint to detect API server failures
  • A dashboard UI availability check confirming the web interface is accessible
  • A test execution endpoint check to verify pipelines can trigger test runs via REST
  • An SSL certificate monitor for your Testkube API and dashboard domain
  • A heartbeat integration to confirm your test suites are completing on schedule

Prerequisites

  • Testkube installed in a Kubernetes cluster via the Helm chart (version 1.14+ or 2.x)
  • Testkube API server and dashboard exposed via Ingress or LoadBalancer with a DNS name
  • The testkube CLI installed locally or in CI/CD (optional, for heartbeat integration)
  • A free account at vigilmon.online

Step 1: Understand Testkube's Health Endpoints

Testkube's API server exposes HTTP health endpoints for liveness and readiness probes. The primary endpoint is:

curl https://testkube.example.com/health
# Returns: {"status":"pass"}

For the readiness probe that confirms MongoDB and MinIO (artifact storage) connectivity:

curl https://testkube.example.com/ready
# Returns HTTP 200 when all dependencies are connected

The Testkube Agent (used in Pro/Cloud setups) also exposes:

curl https://testkube.example.com/api/v1/info
# Returns version and cluster info as JSON

A healthy response returns 200. If Testkube's API server pod is crashed, MongoDB is unreachable, or MinIO is unavailable, the health endpoint returns a non-200 status or a connection error.

Step 2: Create a Vigilmon HTTP Monitor for the API Health Endpoint

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://testkube.example.com/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: pass (present in the health response body).
  7. Click Save.

This monitor catches:

  • Testkube API server pod crashes or out-of-memory restarts
  • MongoDB connection failures that prevent test result storage and retrieval
  • MinIO object storage failures that prevent test artifact access
  • Kubernetes API server connectivity issues affecting test job scheduling
  • Upgrade failures that leave the Testkube API in a broken state

Alert sensitivity: Set to trigger after 1 consecutive failure. When the Testkube API is down, no test runs can be initiated, no results can be retrieved, and CI/CD pipelines that depend on Testkube for post-deployment verification will fail or hang.

Step 3: Monitor the Testkube Dashboard

Testkube's web dashboard provides the interface for browsing test definitions, viewing test run history, inspecting execution logs, and managing executors and test suites. Platform engineers use it to diagnose failing test runs and configure new test types:

curl https://testkube.example.com
# Returns HTML containing "Testkube" in the page content
  1. Add Monitor → HTTP.
  2. URL: https://testkube.example.com (or the dedicated dashboard URL if different from the API).
  3. Check interval: 2 minutes.
  4. Response timeout: 20 seconds.
  5. Expected status: 200.
  6. Keyword: Testkube (appears in the dashboard HTML).
  7. Label: Testkube dashboard.
  8. Click Save.

In many Testkube deployments, the API and dashboard are served on separate subdomains (api.testkube.example.com and dashboard.testkube.example.com) or separate ports. If that is your configuration, set up two monitors — one for the API host and one for the dashboard host — so you can distinguish API routing failures from dashboard serving failures.

Step 4: Monitor the Test Execution REST API

Testkube exposes a REST API that CI/CD pipelines use to trigger test and test suite runs programmatically. This is the endpoint your GitHub Actions, GitLab CI, or Tekton pipelines call after a deployment to initiate post-deployment verification tests:

# Verify the test execution API endpoint is reachable
curl -H "Content-Type: application/json" \
  https://testkube.example.com/api/v1/tests
# Returns 200 with a list of tests, or 401 if authentication is required
  1. Add Monitor → HTTP.
  2. URL: https://testkube.example.com/api/v1/tests.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200 (or 401 if API key authentication is enabled).
  6. Label: Testkube test execution API.
  7. Click Save.

Testkube Pro API Keys: Testkube Pro and Cloud deployments require API key authentication. Configure the Vigilmon monitor to pass an Authorization: Bearer <token> header so it receives a 200 rather than a 401. This confirms not only that the endpoint is reachable but also that authentication is functioning — a more complete liveness check for production environments.

Step 5: Monitor the Test Runner WebSocket Port

Testkube streams real-time test execution logs to the dashboard and CLI over WebSocket connections. The WebSocket endpoint is typically exposed on the same HTTPS port as the REST API, but a TCP-level check confirms the port is accepting connections at the network layer:

# Test TCP connectivity
nc -zv testkube.example.com 443

For Testkube installations that expose the API on a non-standard port (e.g., 8088 in some self-hosted configurations):

nc -zv testkube.example.com 8088
  1. Add Monitor → TCP.
  2. Host: testkube.example.com.
  3. Port: 443 (or your custom API port).
  4. Check interval: 2 minutes.
  5. Label: Testkube API TCP port.
  6. Click Save.

TCP monitoring is particularly useful for Testkube installations running behind corporate firewalls or VPNs, where a successful HTTP check might be served from a proxy cache while the actual Testkube pod is unreachable. A TCP check at the port level bypasses caching layers and confirms the real service is responding.

Step 6: Monitor SSL Certificates

Testkube is accessed by CI/CD pipelines, the testkube CLI, and engineers' browsers. An expired certificate breaks all three — and because test failures in CI/CD often manifest as generic TLS errors rather than clear "certificate expired" messages, proactive certificate monitoring prevents confusing CI/CD failures:

openssl s_client -connect testkube.example.com:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: testkube.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Testkube clusters often run in dedicated namespaces with restrictive NetworkPolicies. If cert-manager's ACME HTTP-01 challenge is blocked by a NetworkPolicy applied to the testkube namespace, Let's Encrypt renewal silently fails. Monitoring with a 30-day lead time ensures you have room to investigate policy rules before the certificate expires.

Step 7: Integrate Vigilmon Heartbeat Pings into Testkube Test Runs

Use Vigilmon's heartbeat monitoring to confirm your Testkube test suites are completing successfully on schedule. This pattern catches silent CI/CD failures — scenarios where the test runner is healthy but the workflow that triggers it has broken:

# In your CI/CD pipeline, after a Testkube test suite completes successfully:
testkube run testsuite post-deployment-suite --watch
TESTKUBE_EXIT=$?

if [ $TESTKUBE_EXIT -eq 0 ]; then
  # All tests passed — send heartbeat to confirm successful run
  curl -m 10 --retry 3 https://vigilmon.online/api/v1/heartbeat/YOUR_HEARTBEAT_ID
fi

Or using the Testkube REST API from a shell script:

EXECUTION_ID=$(curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TESTKUBE_API_TOKEN" \
  https://testkube.example.com/api/v1/test-suites/post-deployment-suite/executions \
  | jq -r '.id')

# Poll until complete, then check status
STATUS=$(curl -s \
  -H "Authorization: Bearer $TESTKUBE_API_TOKEN" \
  https://testkube.example.com/api/v1/test-suite-executions/$EXECUTION_ID \
  | jq -r '.status')

if [ "$STATUS" = "passed" ]; then
  curl -m 10 --retry 3 https://vigilmon.online/api/v1/heartbeat/YOUR_HEARTBEAT_ID
fi

Create the heartbeat monitor in Vigilmon:

  1. Add Monitor → Heartbeat.
  2. Expected interval: Match your deployment schedule (e.g., 30 minutes if post-deployment tests run after every deployment).
  3. Grace period: 10 minutes.
  4. Label: Testkube post-deployment suite.
  5. Click Save, copy the unique heartbeat URL, and add it to your pipeline.

Step 8: Configure Alerting

In Vigilmon under Settings → Notifications, set up alert channels:

| Monitor | Trigger | Action | |---|---|---| | /health | Non-200 or pass missing | Check Testkube API server pod; verify MongoDB and MinIO connectivity | | Dashboard | Non-200 or keyword missing | Frontend serving issue; check dashboard deployment and ingress rules | | Test execution API | Non-200/401 response | CI/CD test triggers will fail; check API routing and authentication | | TCP port | Connection refused | Network/LB issue; check ingress controller and firewall rules | | SSL certificate | < 30 days to expiry | Renew certificate; check cert-manager in the Testkube namespace | | Heartbeat | No ping received | CI/CD pipeline stopped running tests; investigate pipeline and job scheduler |

Alert after: 1 consecutive failure for the API health and TCP monitors. 2 consecutive failures for dashboard and test execution API monitors.

Common Testkube Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Testkube API server pod OOM killed | /health returns connection error; alert within 60 s | | MongoDB unavailable | Health check returns non-pass; test results cannot be stored | | MinIO object storage unavailable | API may appear healthy; artifact downloads fail during test runs | | Dashboard pod crash | Dashboard keyword monitor fires; API health stays green | | Test execution API routing broken | Test API monitor fires; CLI works but REST integrations fail | | SSL certificate expired | SSL monitor alerts; all CLI and CI/CD connections fail with TLS error | | TCP port blocked after network change | TCP monitor fires; connections refused at load balancer level | | CI/CD pipeline stops triggering tests | Heartbeat monitor fires after grace period | | Testkube upgrade breaks API | /health returns errors or schema mismatch after version update | | Kubernetes node pressure evicts Testkube pods | API monitor fires; check kubectl get pods -n testkube for evicted pods |

Testkube puts test execution at the heart of your Kubernetes deployment pipeline — when it fails, post-deployment verification stops running, leaving your team without confirmation that newly deployed services are working correctly inside the cluster. Vigilmon gives you external visibility across every layer of Testkube's availability: the API health endpoint, web dashboard, test execution REST API, TCP connectivity, SSL certificate expiry, and scheduled heartbeat pings that confirm your test suites are actually completing on schedule.

Start monitoring Testkube in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles