Highlight.io is the open-source full-stack monitoring platform that captures session replays, JavaScript errors, backend traces, and structured logs in a single unified interface. It serves React, Next.js, Vue, Angular, Node.js, Go, Python, and Ruby applications. When Highlight's collector endpoint goes down, your frontend SDKs silently drop error events and session recordings, leaving you blind to production issues the moment you need visibility most. When the Highlight frontend script fails to load, session replay stops entirely without any error surfacing in your application logs. Vigilmon gives you external uptime monitoring for Highlight.io — collector endpoint availability, script CDN health, SSL certificate validity, and alerting before your observability layer goes dark.
What You'll Build
- An HTTP monitor on Highlight's ingest collector endpoint to detect ingestion failures
- A monitor on the Highlight JavaScript SDK CDN to catch script loading failures
- An SSL certificate monitor for your Highlight instance domain
- Alerting rules that page your team before error data goes missing
Prerequisites
- A running Highlight.io instance — self-hosted (
https://highlight.example.com) or Highlight Cloud (https://app.highlight.io) - The Highlight collector endpoint network-reachable from Vigilmon probes
- A free account at vigilmon.online
Step 1: Understand Highlight's Ingest Architecture
Highlight.io separates the frontend SDK (loaded by browsers) from the backend collector that receives ingested events. The critical external-facing components are:
| Component | Default path | Role |
|---|---|---|
| Collector / ingest endpoint | /otel/v1/traces, /errors/ingest | Receives session replay events, errors, traces from SDKs |
| Public graph API | /public | GraphQL endpoint for session metadata |
| Frontend app / dashboard | / | Browser-accessible dashboard |
| Highlight client script | CDN URL | JavaScript SDK loaded by monitored applications |
For self-hosted Highlight, all components run under a single domain. For Highlight Cloud, the collector runs at pub.highlight.io and the dashboard at app.highlight.io.
Step 2: Monitor the Collector Endpoint
The collector is the most critical component — it is the intake point for all session replay data, errors, and traces from your applications. A liveness check on the base collector path confirms the service is accepting connections:
curl -I https://highlight.example.com/otel/v1/traces
# A 200 or 405 (method not allowed for GET) confirms the endpoint is alive
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://highlight.example.com/otel/v1/traces(orhttps://pub.highlight.io/otel/v1/tracesfor Highlight Cloud). - Check interval: 60 seconds.
- Response timeout: 15 seconds.
- Expected status:
200or405(GET returns 405 on a POST-only ingest endpoint — set the expected status to match your instance). - Label:
Highlight collector ingest endpoint. - Click Save.
This monitor catches:
- Highlight backend container crashes
- Kubernetes pod failures on the collector deployment
- Load balancer misconfigurations that drop ingest traffic
- Out-of-memory kills on self-hosted Highlight deployments
Alert sensitivity: Set to trigger after 1 consecutive failure. A single collector outage means every monitored application stops shipping data immediately.
Step 3: Monitor the Highlight Dashboard Health
The Highlight frontend app at / serves the dashboard that engineers use to review sessions, errors, and traces. An HTTP check on the dashboard confirms the web layer is serving requests:
curl -I https://highlight.example.com
# Returns 200 with text/html content
- Add Monitor → HTTP.
- URL:
https://highlight.example.com(orhttps://app.highlight.iofor Cloud). - Check interval: 60 seconds.
- Response timeout: 15 seconds.
- Expected status:
200. - Keyword:
Highlight(appears in the page title). - Label:
Highlight dashboard. - Click Save.
Self-hosted note: On self-hosted deployments, the dashboard and collector share the same service. If the dashboard 404s or times out, collector health is likely degraded as well.
Step 4: Monitor the Public GraphQL Endpoint
Highlight exposes a /public GraphQL endpoint for SDK initialization and session metadata. If this endpoint is down, SDK initialization fails, preventing new sessions from being created even if the collector is otherwise available:
curl -I https://highlight.example.com/public
# Returns 200 or 400 for a bare GET (expects a POST with GraphQL body)
- Add Monitor → HTTP.
- URL:
https://highlight.example.com/public. - Check interval: 2 minutes.
- Response timeout: 10 seconds.
- Expected status:
200or400(bare GET to a GraphQL endpoint often returns 400 — confirm for your instance). - Label:
Highlight public GraphQL API. - Click Save.
Step 5: Monitor SSL Certificates
Highlight's TLS certificate protects both the dashboard and the SDK ingest endpoint. An expired certificate causes browsers to block the Highlight script from loading, stopping session replay for all users of your monitored applications:
openssl s_client -connect highlight.example.com:443 2>/dev/null | openssl x509 -noout -dates
- Add Monitor → SSL Certificate.
- Domain:
highlight.example.com. - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
Why SSL matters for Highlight specifically: Unlike most services where an expired certificate stops human users, an expired Highlight certificate silently breaks automated SDKs embedded in your applications. Your React or Next.js Highlight snippet will fail to send data, and you will not see errors in your application — you simply stop receiving sessions.
Step 6: Monitor the Highlight SDK Script CDN (Self-Hosted)
For self-hosted deployments that serve the Highlight JavaScript SDK from their own domain, monitoring the script URL ensures your monitored applications can load the SDK:
curl -I https://highlight.example.com/dist/index.js
# Returns 200 with JavaScript content
- Add Monitor → HTTP.
- URL:
https://highlight.example.com/dist/index.js(adjust path to your self-hosted SDK URL). - Check interval: 5 minutes.
- Response timeout: 15 seconds.
- Expected status:
200. - Label:
Highlight SDK script. - Click Save.
For Highlight Cloud users, the SDK is served from Highlight's own CDN and is covered by Highlight's uptime SLA — skip this step for Cloud deployments.
Step 7: Configure Alerting
In Vigilmon under Settings → Notifications, configure your alert channels:
| Monitor | Trigger | Action | |---|---|---| | Collector ingest endpoint | Non-200/405 response or timeout | Check Highlight backend pod; inspect ingestion queue; review container logs | | Dashboard | Non-200 or keyword missing | Highlight frontend service degraded; check web container health | | Public GraphQL API | Unexpected status | SDK initialization failing; new sessions not being created | | SSL certificate | < 30 days to expiry | Renew certificate; verify SDK can still connect after renewal | | SDK script CDN | Non-200 response | Applications cannot load Highlight SDK; session replay stops immediately |
Alert after: 1 consecutive failure for the collector endpoint. 2 consecutive failures for dashboard and API monitors.
Common Highlight.io Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor | |---|---| | Backend container OOM killed | Collector monitor fires; all SDK ingestion stops silently | | Database connection pool exhausted | Collector returns 500; monitor fires within 60 s | | Kafka/Redis queue full (self-hosted) | Ingest endpoint returns errors; collector monitor fires | | SSL certificate expired | SSL monitor alerts at 30-day threshold; browser blocks SDK load | | SDK script 404 after deploy | SDK monitor fires; session replay stops for all applications | | Ingress misconfiguration after k8s upgrade | Collector and dashboard monitors fire simultaneously | | DNS cutover failure | All monitors fire; application SDKs cannot reach collector | | Frontend container crash | Dashboard monitor fires; collector may still accept data | | Self-hosted disk full (session storage) | Ingest returns 500; collector monitor fires | | High-traffic event causes collector overload | Collector response time increases; Vigilmon timeout alert fires |
Monitoring Data Completeness vs. Service Availability
Vigilmon monitors whether Highlight's endpoints are reachable — it does not verify that events are being processed end-to-end. For deeper data quality monitoring:
- Session gap detection: If you stop receiving sessions for a known active project, check the collector monitor status and inspect Highlight's internal queue health.
- Error rate spikes: Highlight's own dashboard shows error ingestion rates — a sudden drop combined with a healthy collector suggests a frontend SDK configuration issue.
- Worker queue depth: For self-hosted deployments, monitor your Kafka/Redis queue depth separately to detect ingestion backlogs that don't surface as HTTP errors.
Vigilmon catches infrastructure-level failures — endpoint unreachability, certificate expiry, service crashes. End-to-end data completeness requires Highlight's internal metrics alongside external uptime monitoring.
Highlight.io gives you session replay and error monitoring across your entire stack, but your observability layer itself needs monitoring. A Highlight collector that goes down silently stops ingesting errors and session data from every application it monitors — you lose the exact visibility you need during incidents. Vigilmon checks Highlight's ingest endpoint, dashboard, GraphQL API, and SSL certificate on a 60-second cycle, so you know within a minute when your observability platform stops collecting data.
Start monitoring Highlight.io in under 5 minutes — register free at vigilmon.online.