Building a Complete Observability Strategy in 2026: The Four Pillars

The three pillars of observability — metrics, logs, and traces — have become foundational doctrine in modern platform engineering. If your team is running Prometheus, Grafana, and OpenTelemetry, you have solid internal visibility into how your systems are behaving.

But there is a fourth pillar that most observability stacks leave out entirely: external availability. And it is the only pillar that reflects what your users actually experience.

This guide explains how to layer external uptime monitoring on top of an existing metrics/logs/traces stack to build a complete observability strategy.

The Three Pillars (and Their Shared Blind Spot)

Metrics (Prometheus, Datadog, CloudWatch) give you time-series data about system behaviour: CPU usage, memory consumption, request rates, error rates, cache hit ratios. Metrics tell you how your systems are performing in aggregate.

Logs (ELK, Loki, Axiom) give you event-level detail: which requests failed, what error messages appeared, which user triggered which action. Logs tell you what happened at a point in time.

Traces (Jaeger, Tempo, Honeycomb) connect events across distributed systems: a single user request traced through a frontend service, three microservices, a database, and a cache. Traces tell you where time was spent in a complex call graph.

All three of these pillars share one structural blind spot: they are inside-out. They observe your systems from within your infrastructure. They cannot tell you whether a user in Singapore can reach your API. They cannot tell you if a CDN misconfiguration is returning 503s to users in a specific region. They cannot tell you if an SSL certificate expired and is blocking HTTPS connections before a single request even reaches your load balancer.

The Fourth Pillar: External Availability

External availability monitoring answers the question that metrics, logs, and traces cannot: Can users actually reach my service right now?

This is the view from the outside — from the user's perspective, from a network that is not your own, through the full routing path that real traffic follows. External availability monitoring checks your endpoints from external vantage points on a schedule and alerts your team the moment a check fails.

| Pillar | Tool Examples | What It Answers | |---|---|---| | Metrics | Prometheus, Datadog | How is the system performing? | | Logs | Loki, Axiom, ELK | What happened at a specific time? | | Traces | Jaeger, Honeycomb | Where did time go in a request? | | External Availability | Vigilmon | Can users actually reach the service? |

Why Internal Observability Is Blind to External Failures

Consider these failure scenarios that are invisible to metrics, logs, and traces:

DNS failure — your DNS provider has an outage. Your pods are running, your metrics look normal, your logs show no errors. But no user can resolve your domain. Prometheus does not monitor DNS resolution from the public internet.

CDN misconfiguration — a Cloudflare page rule change starts returning 503s to users while your origin servers are perfectly healthy. Your internal metrics show zero error rate. Vigilmon, checking from the public internet, immediately sees the 503.

SSL certificate expiry — your certificate expired. HTTPS connections fail with a TLS error before they reach your load balancer. No application logs are generated. No traces start. No internal metrics catch it.

Routing asymmetry — a BGP announcement causes traffic from certain ISPs to be dropped. Users in affected regions get timeouts. Your internal metrics show normal traffic levels from the ISPs that are still routing correctly.

In every one of these cases, your three-pillar observability stack is silent. External availability monitoring catches all of them.

Layering Vigilmon on a Prometheus/Grafana/OpenTelemetry Stack

Adding external availability to an existing stack requires no instrumentation changes. You configure monitors in Vigilmon — URLs, check intervals, expected responses — and Vigilmon runs checks from external vantage points.

What to monitor externally:

• Customer-facing frontend URLs (homepage, login page, key product pages)
• Public-facing API endpoints (health check, auth endpoint, primary API routes)
• Third-party dependencies your app calls (payment provider, SMS gateway, identity provider)
• Internal tools that cross network boundaries (VPN-accessible services from external IPs)
• Certificate expiry (Vigilmon can alert before certificates expire)

Correlating external alerts with internal telemetry:

When Vigilmon fires an alert, the first question is whether the failure is external (routing, DNS, CDN) or internal (application error, database). A practical workflow:

1. Vigilmon alert fires — the service is unreachable from outside
2. Check Grafana dashboards — are internal metrics normal or elevated?
3. If metrics are normal: the problem is external (DNS, CDN, routing). Check external dependencies.
4. If metrics are abnormal: the problem is internal. Open traces for recent requests in the time window of the failure.
5. Drill into logs to find the root cause signal.

This triage path takes minutes when you have all four pillars in place. Without Vigilmon, step 1 does not exist — you rely on a user to file a support ticket before you know anything is wrong.

Alert Routing Strategy

A complete observability strategy also needs a coherent alert routing strategy. The failure mode here is alert fatigue: too many alerts, too many channels, too little signal.

A practical approach:

Vigilmon alerts → immediate on-call page. An external availability failure is always customer-impacting. Route to PagerDuty or your on-call system.

Prometheus alerting rules → Slack and optionally on-call. Degraded performance metrics (high latency, elevated error rate) are important but often have lead time before they become customer-visible. Route to #engineering-alerts.

Log-based alerts → Slack or email. Patterns in logs (repeated error codes, security events) are investigative signals, not necessarily immediate incidents.

Traces → on-demand during incidents. Traces are not an alerting tool — they are a debugging tool you pull when you already know something is wrong.

Escalation: From Uptime Alert to Trace Investigation

The ideal incident flow in a four-pillar stack:

1. Vigilmon fires: external availability check failed for /api/payments
2. On-call engineer acknowledges, checks Grafana: error rate is spiking in the payment service
3. Engineer opens Jaeger/Tempo: finds traces from the last 5 minutes, sees database query timeouts in the critical path
4. Engineer checks Loki/Axiom: searches for database connection errors in the time window, finds connection pool exhaustion error
5. Root cause identified in under 5 minutes

Without the external uptime alert in step 1, the engineer might not have known to look at the payment service at all. The alert is the starting gun.

Getting Started

If you already run Prometheus + Grafana + OpenTelemetry and want to add the fourth pillar:

1. Add your three highest-traffic customer-facing endpoints as Vigilmon monitors
2. Configure alerts to your existing on-call system (PagerDuty, Opsgenie)
3. Add your primary API health endpoint
4. Add any third-party dependencies that would cause customer-facing failures

That is a complete starting point in under 10 minutes.

Conclusion

Metrics, logs, and traces give you deep internal visibility into your systems. External availability monitoring gives you the view your users have. Together, they form a complete observability strategy that catches failures at every layer — from inside your pods to the public internet routing path between your users and your infrastructure.

Add external availability monitoring to your observability stack — free for your first 3 monitors.