Monitoring Cube (Cube Dev) with Vigilmon: REST API, GraphQL API, Health Endpoint & SSL

Cube is the semantic layer and analytics API platform that sits between your data warehouse and every dashboard, data app, and BI tool your business relies on. When Cube's REST API goes down, every chart in every dashboard stops loading. When the GraphQL API is unavailable, data apps that power internal tooling and customer-facing analytics return blank screens. When pre-aggregation builds fail silently, query performance degrades and warehouse costs spike from full-table scans. Vigilmon gives you external visibility into Cube's availability: the REST API, GraphQL API, health endpoint, and SSL certificate health.

What You'll Build

An HTTP monitor on Cube's health endpoint to detect service-level failures
A REST API availability check to confirm query execution is working
A GraphQL API monitor for teams using the GraphQL interface
SSL certificate monitoring for your Cube deployment domain
An alerting setup that distinguishes routing failures from query execution degradation

Prerequisites

A running Cube deployment (Cube Cloud or self-hosted via cubejs-server / @cubejs-backend/server)
Your Cube API URL (e.g., https://cube.example.com or your Cube Cloud URL)
The Cube REST API base path (/cubejs-api/v1)
A free account at vigilmon.online

Step 1: Understand Cube's External-Facing API Surface

Cube exposes several endpoints relevant to external health monitoring:

| Endpoint | Role | |---|---| | /cubejs-api/v1/ | REST API root — meta, load, and dry-run endpoints | | /cubejs-api/v1/meta | Schema metadata — confirms Cube is connected to the data source | | /cubejs-api/v1/graphql | GraphQL API — alternative query interface | | /cubejs-api/v1/readyz | Kubernetes-style readiness probe | | /cubejs-api/v1/livez | Kubernetes-style liveness probe |

The readiness and liveness probes are the canonical health signals for Cube deployments. The /meta endpoint is the best functional check because it confirms Cube has successfully connected to the data warehouse and loaded the data schema.

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

Cube exposes /cubejs-api/v1/readyz as a readiness probe. When this endpoint returns non-200, Cube is not ready to serve queries — either because it's still connecting to the warehouse, the schema hasn't loaded, or a container restart is in progress:

curl https://cube.example.com/cubejs-api/v1/readyz
# Returns: {"ready":true} when healthy

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://cube.example.com/cubejs-api/v1/readyz.
Check interval: 60 seconds.
Response timeout: 15 seconds.
Expected status: 200.
Keyword: ready (appears in the {"ready":true} response).
Click Save.

This monitor catches:

Cube API server crashes or container restarts
Data warehouse connection failures preventing schema load
Deployment failures during Cube upgrades
Kubernetes pod failures in containerized deployments

Alert sensitivity: Set to trigger after 1 consecutive failure. When Cube's readiness probe fails, every consumer of the analytics API — dashboards, data apps, BI tools — is returning errors to end users.

Step 3: Monitor the REST API Meta Endpoint

The /meta endpoint returns the Cube data schema — all cubes, dimensions, measures, and segments available for querying. A healthy response confirms that Cube has successfully connected to the data warehouse and compiled the schema:

# Meta endpoint requires auth — check for expected response structure
curl -H "Authorization: <your-api-token>" \
  https://cube.example.com/cubejs-api/v1/meta
# Returns JSON with "cubes" array when healthy

For a Vigilmon probe without embedding API tokens, check the /livez endpoint instead:

curl https://cube.example.com/cubejs-api/v1/livez
# Returns: {"alive":true}

Add Monitor → HTTP.
URL: https://cube.example.com/cubejs-api/v1/livez.
Check interval: 60 seconds.
Response timeout: 10 seconds.
Expected status: 200.
Keyword: alive.
Label: Cube liveness probe.
Click Save.

Cube Cloud: If you're using Cube Cloud, your deployment URL follows the format https://<deployment-id>.cubecloud.dev. Use the same /cubejs-api/v1/livez and /readyz paths against your Cube Cloud URL.

Step 4: Monitor the REST API Query Surface

Beyond liveness checks, it's valuable to confirm Cube can actually serve query traffic. The /cubejs-api/v1/load endpoint executes queries — but for a lightweight availability probe, checking the root API path or performing a minimal dry-run is sufficient:

# Check that the REST API root is reachable
curl -I https://cube.example.com/cubejs-api/v1/
# Returns HTTP 200 or 401 depending on your auth config

Add Monitor → HTTP.
URL: https://cube.example.com/cubejs-api/v1/.
Check interval: 60 seconds.
Response timeout: 10 seconds.
Expected status: 200 (or 401 if your Cube deployment requires auth on all endpoints).
Label: Cube REST API.
Click Save.

Step 5: Monitor the GraphQL API

Teams using Cube's GraphQL interface query metrics from frontend applications and internal tools. If the GraphQL endpoint is down, those applications fail to load data:

# GraphQL endpoint — a POST to this URL executes queries
curl -I https://cube.example.com/cubejs-api/v1/graphql
# Returns HTTP 405 (Method Not Allowed for GET) or 401 — confirms the endpoint exists

Add Monitor → HTTP.
URL: https://cube.example.com/cubejs-api/v1/graphql.
Check interval: 2 minutes.
Response timeout: 10 seconds.
Expected status: 405 (GraphQL endpoint is POST-only; a GET returns 405, confirming the route exists) or 401.
Label: Cube GraphQL API.
Click Save.

Note: If your Cube deployment returns a different status code for GET requests to the GraphQL endpoint (e.g., 200 with a playground UI), adjust the expected status accordingly.

Step 6: Monitor SSL Certificates

Cube's REST and GraphQL APIs are accessed over HTTPS by dashboards, BI tools, and data apps. An expired certificate causes all of these to fail with TLS errors, blocking every data consumer simultaneously:

openssl s_client -connect cube.example.com:443 2>/dev/null | openssl x509 -noout -dates

Add Monitor → SSL Certificate.
Domain: cube.example.com (or your Cube Cloud URL).
Alert when expiry is within: 30 days.
Alert again: 14 days, 7 days, 3 days, 1 day.
Click Save.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Readiness probe | Non-200 or ready missing | Cube not ready; check warehouse connection; inspect container logs | | Liveness probe | Non-200 or alive missing | Cube process crashed; restart container; check Kubernetes pod status | | REST API | Non-200/non-401 | API routing failure; check ingress/load balancer; review Cube server logs | | GraphQL API | Non-405/non-401 | GraphQL endpoint unavailable; check if Cube was restarted without GraphQL enabled | | SSL certificate | < 30 days to expiry | Renew certificate; test API connectivity after renewal |

Alert after: 1 consecutive failure for readiness, liveness, and REST API monitors. 2 consecutive failures for the GraphQL monitor.

Common Cube Dev Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Cube API container OOM killed | Readiness and liveness monitors fire; all downstream dashboards break | | Data warehouse connection failure | Readiness probe fails; schema not loaded; queries return errors | | Pre-aggregation build failure | API stays live; query performance degrades; not directly caught by HTTP checks | | Ingress/load balancer misconfiguration | REST API monitor catches routing failures | | SSL certificate expiry | SSL monitor alerts; all API consumers fail with TLS errors | | Cube schema compilation error | Readiness probe fails; meta endpoint returns errors | | Redis cache failure (if using external Redis) | API still responds; caching disabled; query latency spikes | | Kubernetes node eviction | Readiness probe fires; pod reschedules on healthy node | | Multi-tenant deployment: one tenant down | Use separate monitors per tenant endpoint |

Monitoring Pre-Aggregation Health

Cube's pre-aggregations (materialized query results) are critical for query performance. Failed pre-aggregation builds don't show up in uptime monitoring — they cause slow queries and warehouse cost spikes:

Cube Cloud: Use the Cube Cloud dashboard's pre-aggregations tab to view build status and failure reasons.
Self-hosted: Cube logs pre-aggregation build failures with the message Pre-aggregation ... build failed. Set up log-based alerting in your logging stack (Datadog, Loki, CloudWatch) for these patterns.
Query latency monitoring: Vigilmon's HTTP monitor doesn't measure query latency, but if you have a public or lightly-authenticated endpoint, a response-time alert can signal pre-aggregation degradation.

Vigilmon catches infrastructure-level failures. Pre-aggregation build health requires Cube-specific observability via logs or the Cube Cloud dashboard.

Cube is the semantic layer that decouples your data warehouse from every dashboard and data application in your business. When it goes down, no dashboard loads data, no BI query returns results, and no data app shows metrics — across every team and every product that depends on analytics. Vigilmon gives you external visibility into Cube's availability from outside your infrastructure: readiness and liveness probes, REST API health, GraphQL API access, and SSL certificate expiry, so you know the moment Cube becomes unreachable and can restore analytics access before engineers start debugging blank dashboards.

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