Vigilmon vs Lightstep — now ServiceNow Cloud Observability — is a comparison between an outside-in uptime monitoring service and a distributed tracing platform designed to analyze latency and request flows inside complex distributed systems. Lightstep was built to answer performance questions that traditional metrics can't surface: why is the p99 latency for this specific customer's requests degrading, and which microservice in the call chain is responsible? Vigilmon was built to answer a different class of question: is your service actually reachable from the outside world, right now, confirmed by independent external probes?
The comparison matters because both tools address reliability concerns, but from structurally different perspectives. Lightstep traces requests as they travel through your instrumented code. Vigilmon probes your services from outside, the same way your users experience them. Neither tool replaces the other — understanding what each one does and doesn't cover clarifies when you need both.
What Is Lightstep (ServiceNow Cloud Observability)?
Lightstep was founded by former Google SRE engineers who built some of the internal distributed tracing infrastructure at Google. ServiceNow acquired Lightstep in 2021 and rebranded it as ServiceNow Cloud Observability. The product focuses on distributed tracing, latency analysis, and change intelligence — helping engineering teams understand the performance behavior of their distributed services at the request level.
Core Lightstep Capabilities
Distributed tracing with OpenTelemetry: Lightstep ingests OpenTelemetry traces — the industry-standard structured event spans that track a request's journey through every service, database call, cache hit, and external API in a distributed system. A single user request can generate dozens or hundreds of spans across an architecture. Lightstep stores and indexes these spans for analysis.
Latency analysis: Lightstep's primary strength is latency analysis — understanding the performance distribution of requests through your system. Rather than knowing "average latency increased," Lightstep lets you drill into p50/p95/p99 distributions, break them down by service or operation, and identify exactly which component in the call chain is responsible for tail latency.
Change correlation: Lightstep's change intelligence feature correlates latency shifts with code deploys, configuration changes, and infrastructure events. If a deploy increased p99 latency, Lightstep can surface the correlation automatically — comparing trace behavior before and after the change.
Service health and dependency maps: Lightstep generates service maps from trace data, showing the call relationships between services and the latency and error rate of each edge in the dependency graph. This makes it easier to identify which upstream or downstream service dependency is causing a degradation.
Alerting on trace-derived metrics: Lightstep supports alerts based on derived metrics from trace data — error rate, latency percentiles, request volume — as well as static and dynamic baselines. These alerts fire when trace-based signals exceed configured thresholds.
OpenTelemetry-first design: Lightstep was an early adopter and contributor to the OpenTelemetry standard and built its platform around OTLP-native ingestion. This means teams with existing OpenTelemetry instrumentation can send data to Lightstep without vendor-specific SDKs.
Lightstep's Philosophy: Latency Root Cause from Traces
Lightstep was designed specifically for the engineering problem of diagnosing latency issues in distributed systems. The founding team came from production systems where p99 latency regressions were the most common and hardest-to-diagnose production issues. The product's core capability — correlating latency changes with specific operations, services, or deploys — reflects this origin.
This is powerful for performance engineering and incident investigation. But it shares the same structural constraint as all trace-based observability: it depends on your instrumented application being healthy enough to generate and emit trace events.
What Is Vigilmon?
Vigilmon is an agentless, outside-in uptime monitoring service. No instrumentation libraries, no SDK configuration, no trace collector to operate. Vigilmon probes your services from multiple geographically distributed probe nodes and alerts only when a majority of those probes independently confirm a failure — a consensus model that eliminates single-probe false positives.
Vigilmon monitors:
- HTTP/HTTPS endpoints — status code validation, response body matching, SSL certificate expiry warnings
- TCP ports — raw socket checks for databases, mail servers, and custom services
- Cron job heartbeats — detect silent background job failures when expected pings stop arriving
Features include response time history, embeddable status badges, a REST API, and webhook notifications for Slack, PagerDuty, OpsGenie, and custom endpoints. The free tier is permanent — 5 monitors, no credit card, no expiry.
Feature Comparison
| Feature | Lightstep (ServiceNow) | Vigilmon | |---|---|---| | Distributed tracing (OpenTelemetry) | ✅ | ❌ | | Latency analysis (p50/p95/p99) | ✅ | ❌ | | Service maps from trace data | ✅ | ❌ | | Change correlation / deploy tracking | ✅ | ❌ | | Trace-based alerting | ✅ | ❌ | | External HTTP uptime monitoring | ❌ | ✅ | | TCP port monitoring | ❌ | ✅ | | Multi-region consensus alerting | ❌ | ✅ | | Cron / heartbeat monitoring | ❌ | ✅ | | SSL certificate monitoring | ❌ | ✅ | | Agentless setup (zero instrumentation) | ❌ | ✅ | | Outside-in probe perspective | ❌ | ✅ | | Works when application is completely down | ❌ | ✅ | | Webhook / Slack / PagerDuty | ✅ | ✅ | | REST API | ✅ | ✅ | | Free tier | ✅ (limited) | ✅ (5 monitors, permanent) |
Pricing Comparison
Lightstep (ServiceNow Cloud Observability) Pricing
Lightstep pricing is span-based — you pay for the volume of trace spans ingested. As a ServiceNow product, pricing is enterprise-oriented and not publicly listed at list price; enterprise contracts are typically negotiated based on span ingestion volume, team size, and retention requirements.
The per-span pricing model means your Lightstep bill scales with the traffic volume and instrumentation depth of your distributed system. High-traffic services with detailed OpenTelemetry instrumentation — many operations traced, many spans per request — generate more ingestion volume and higher costs. This is expected: you're paying for the storage and query capacity over trace data that reflects your system's actual traffic.
For teams evaluating Lightstep, the cost model requires estimating your span generation rate (requests per second × average spans per request) and how much of that trace data you want to retain and query. At meaningful production scale, costs can be substantial.
Vigilmon Pricing
Vigilmon pricing is monitor-based — you pay for the number of active monitors and check frequency, not for data volume or request traffic.
Free tier (permanent): 5 monitors, 5-minute check intervals, multi-region consensus alerting, email and webhook notifications, response time history. No credit card required, no trial expiry.
Paid plans: Scale with monitor count and check frequency. No per-span charges, no ingestion fees, no retention costs. The total cost of ownership is the monthly subscription.
For teams that need reliable uptime monitoring, Vigilmon's flat monitor-based pricing is significantly more predictable than span-volume pricing that scales with traffic. A team going from 100 req/s to 1,000 req/s sees their Lightstep bill grow proportionally; their Vigilmon bill stays flat because they're monitoring the same number of endpoints.
Inside-Out Traces vs. Outside-In Availability
Lightstep: Inside-Out Instrumentation
Lightstep requires instrumentation inside your application code:
- OpenTelemetry SDK must be integrated into each service
- Trace context propagation must be configured at every service boundary for distributed traces to connect across services
- Span exporters must be configured to ship trace data to Lightstep's ingestion endpoint
- Span generation happens inside your running application — if the application crashes or is unreachable, it generates no spans
The inside-out model provides exceptional visibility into the internal behavior of your distributed system. You can trace a request through every microservice, database call, and cache operation. You can identify which specific operation within a specific service is responsible for latency.
But this model has a structural gap: it only shows you what your running, instrumented application sees. If your application becomes completely unreachable — load balancer misconfiguration, DNS failure, network partition, host crash — no spans are generated. Lightstep has nothing to show you, and its trace-based alerts cannot fire because there's no event data to trigger on.
More subtly: at the exact moment your service is most broken — when requests are timing out before completion, when the application is crashing before emitting spans — your trace data becomes sparse or absent precisely when you most need it.
Vigilmon: Outside-In Availability
Vigilmon probes your services from infrastructure that is structurally independent of your application environment. Vigilmon's probes see your services the same way your users do: by making HTTP requests and waiting for a response.
If your entire application stack collapses — servers crash, load balancers fail, DNS resolves incorrectly, your OpenTelemetry collector goes down — Vigilmon's probes detect the failure from outside and alert you. There is no dependency on your application being healthy enough to emit trace events.
This outside-in perspective fills the gap that traces structurally cannot cover: the period between "something is wrong" and "I have trace data to investigate." When Vigilmon fires a consensus alert, the on-call engineer knows there's a real, externally-confirmed outage before they open Lightstep.
Trace-Based Alerting vs. Probe-Based Alerting
Lightstep: Derived Metric Alerting
Lightstep alerts fire based on derived metrics from trace data — error rate, latency percentile, request volume. You configure a query over trace data and set a threshold that triggers the alert.
This is powerful for internal performance signals: p99 latency exceeding 500ms for a specific service, error rate exceeding 5%, requests per second dropping below baseline. But it inherits the trace data dependency: if your service is unreachable and no spans are arriving, Lightstep's alerts evaluate against empty data and don't fire.
Vigilmon: Consensus Probe Alerting
Vigilmon alerts fire based on direct probe results. Every N minutes, multiple independent probes attempt to reach your endpoint from different geographic locations. If a quorum of probes fails to receive the expected response, an alert fires.
No query configuration required. No event data dependency. The alert model is binary at the probe level: the endpoint returned the expected response or it didn't. The consensus requirement — multiple probes must independently confirm failure — eliminates transient single-probe anomalies from triggering pages.
The Dead Man's Switch Gap
There's a specific failure mode that illustrates Vigilmon's value in a Lightstep deployment: the dead man's switch scenario.
Your service goes completely down. No requests complete. Lightstep receives no spans. Lightstep's derived metric alerts evaluate against zero data — and many implementations treat zero data as "no signal," not as an alert condition. Your on-call engineer isn't paged.
Meanwhile, your users are getting connection refused or timeout errors. The support queue starts filling.
Vigilmon's probes detect this scenario directly. The probes can't reach your service. Multiple independent probes confirm the failure. A consensus alert fires. Your on-call engineer gets a page before the support queue overflows.
Span-Based Root Cause vs. Availability Alerting
The operational sequence for mature reliability teams often looks like this:
-
Vigilmon fires first — a consensus alert confirms service unreachability from the outside world. The on-call engineer is paged. They know there's a real outage, not a transient single-probe blip.
-
Lightstep provides investigation context — once alerted, the engineer opens Lightstep to review the last traces before the outage, identify which service or operation started degrading, and correlate with recent deploys.
-
Vigilmon confirms recovery — when the service is restored, Vigilmon's probes confirm reachability is restored from the outside, independent of internal metrics.
This sequence reflects what each tool is optimized for: Vigilmon provides the definitive availability signal (is the service reachable?), Lightstep provides the investigation environment (why did it fail?).
When to Choose Lightstep (ServiceNow Cloud Observability)
Lightstep is the better choice when:
- Your primary need is latency analysis and root-cause investigation across distributed microservices
- You need to diagnose why specific customer requests are slow (high-cardinality trace drilling)
- Your team has adopted OpenTelemetry and needs a powerful, OTel-native trace backend
- Deploy-correlated performance regression analysis is a core operational requirement
- You manage service-level objectives based on latency percentiles and error rates
- Your architecture involves many interacting services where understanding call chain latency requires distributed tracing
- Performance debugging — finding the specific service and operation responsible for tail latency — is a regular engineering task
When to Choose Vigilmon
Vigilmon is the better choice when:
- Your primary need is outside-in uptime monitoring — confirming services are reachable before users report outages
- You want monitoring that's structurally independent of your application's internal health and instrumentation pipeline
- You need consensus-based alerting that won't fire on a single probe's transient failure
- You have cron jobs or background workers that need heartbeat monitoring (no traces generated)
- You want monitoring running within minutes — URL entry, no SDK, no instrumentation changes, no collector
- SSL certificate expiry monitoring is a requirement
- Your monitoring cost should not scale with traffic volume — a flat per-monitor cost is preferable to per-span ingestion costs
- Your team needs a permanent free tier to get started without a sales call
Using Both Together
Lightstep and Vigilmon complement each other across different observability layers. Teams operating distributed systems at meaningful scale benefit from both.
Vigilmon provides:
- The first alert — service is unreachable, consensus confirmed from the outside world, independent of trace pipeline health
- Outside-in availability confirmation that doesn't depend on your OpenTelemetry instrumentation working
- Heartbeat monitoring for background jobs that don't generate HTTP traces
- SSL certificate monitoring
- A monitoring layer that remains functional even when your trace infrastructure is part of the incident
Lightstep provides:
- The investigation environment — once Vigilmon fires, engineers open Lightstep to analyze the last traces, correlate with deploys, and pinpoint the degraded service
- Distributed trace correlation across services for debugging complex multi-service failures
- Latency percentile analysis and p99 root cause identification
- Deploy change correlation to identify which code or config change introduced a regression
- SLO management based on trace-derived error rates and latency distributions
The operational model: Vigilmon fires the first alert (service is unreachable, externally confirmed by probe consensus). The on-call engineer opens Lightstep to trace the last requests before the outage, identify which service or operation degraded, and correlate with any recent deploys. Vigilmon confirms when recovery is complete from outside. Lightstep documents what failed and why.
Side-by-Side Summary
| Dimension | Lightstep (ServiceNow) | Vigilmon | |---|---|---| | Primary purpose | Distributed tracing and latency analysis | Service availability monitoring | | Monitoring perspective | Inside-out (instrumented application spans) | Outside-in (external probe network) | | Setup requirement | OpenTelemetry SDK instrumentation + collector | URL entry — no code changes | | Operational overhead | SDK config, collector management, span pipeline | None (fully managed) | | Alert model | Derived metric thresholds on trace data | Multi-region consensus probe results | | Works when app is completely down | ❌ (no spans generated) | ✅ (probes detect outage directly) | | False positive protection | Limited (single-node metric threshold) | ✅ (consensus quorum required) | | Cron heartbeat monitoring | ❌ | ✅ | | SSL monitoring | ❌ | ✅ | | Pricing model | Per-span ingestion (scales with traffic) | Per-monitor flat rate | | Latency root cause analysis | ✅ | ❌ | | Deploy change correlation | ✅ | ❌ | | Service dependency maps | ✅ | ❌ | | Free tier | ✅ (limited) | ✅ (5 monitors, permanent) | | Best for | Latency debugging and distributed trace analysis | Outside-in uptime and availability confirmation |
Conclusion
Vigilmon vs Lightstep is not a "pick one" comparison for teams running distributed services in production. Lightstep (ServiceNow Cloud Observability) excels at what traces reveal: the internal latency structure of your distributed system, which operation in which service is responsible for tail latency, and how code deploys affect performance. Vigilmon excels at what traces structurally cannot reveal: whether your service is reachable from the outside world at all, confirmed by independent external probes before your first user support ticket arrives.
For teams already invested in Lightstep, Vigilmon adds the outside-in availability layer that trace-based monitoring cannot provide: consensus-confirmed alerts that fire even when your application is too broken to emit spans, heartbeat monitoring for background jobs that generate no traces, and a monitoring layer that is structurally independent of your OpenTelemetry pipeline.
The combination is straightforward: Vigilmon detects availability failures from outside. Lightstep diagnoses what happened inside. Neither tool replaces the other, and together they cover the observability surface that either tool alone leaves blind.
Try Vigilmon free at vigilmon.online — no agents, no instrumentation, no credit card, multi-region consensus alerting from the first monitor.
Tags: #monitoring #uptime #lightstep #servicenow #tracing #observability #vigilmon #devops #sre #opentelemetry #latency #2026