Thanos is one of the most powerful tools in the Prometheus ecosystem — but it's frequently mischaracterised as a general-purpose monitoring platform. This comparison explains what Thanos is designed to do, where it stops, and why teams running Thanos still need Vigilmon for external uptime monitoring.
What Is Thanos?
Thanos is a set of components that extend Prometheus for high availability and long-term metrics retention. It was open-sourced by Improbable in 2018 and is now a CNCF incubating project.
At its core, Thanos solves two problems that Prometheus cannot solve alone:
1. Prometheus data doesn't survive restarts. Prometheus stores data locally on disk. If your Prometheus instance fails or you rotate it, you lose historical metrics. Thanos sidecars ship Prometheus blocks to object storage (S3, GCS, Azure Blob) in near-real-time, giving you persistent, low-cost long-term retention.
2. Multiple Prometheus instances create isolated data silos. Large organisations run dozens or hundreds of Prometheus instances — one per cluster, per team, or per region. Thanos's global query layer (thanos query) federates across all of them, letting you run a single PromQL query that spans every Prometheus in your fleet.
Thanos's core components:
- Thanos Sidecar — attaches to each Prometheus pod and uploads blocks to object storage
- Thanos Store Gateway — serves historical blocks from object storage via the Thanos API
- Thanos Query / Query Frontend — deduplicates and federates queries across sidecars and store gateways
- Thanos Compactor — merges and down-samples historical blocks to reduce storage costs
- Thanos Ruler — evaluates recording rules and alerts against global query results
- Thanos Receive — accepts remote write from Prometheus and writes blocks to object storage
Thanos is a sophisticated distributed system. It solves real problems at scale — but all of them are problems about storing and querying metrics that your own services produce.
What Is Vigilmon?
Vigilmon is a purpose-built external uptime monitoring service. Rather than collecting data from inside your infrastructure, Vigilmon probes your services from the outside — multiple independent geographic locations — and alerts your team when users can't reach your endpoints.
Vigilmon's core capabilities include:
- HTTP/HTTPS endpoint monitoring with status code and response body validation
- TCP port monitoring for non-HTTP services
- Cron job heartbeat monitoring (dead man's switch for scheduled functions)
- Multi-region consensus alerting — only fires when a quorum of probes agree the target is down
- Response time history with configurable period selectors
- Webhook, email, and Slack alert channels
- Embeddable status page badges for customer-facing transparency
Setup takes two minutes. There's no sidecar to deploy, no object store bucket to configure, no query component to scale.
The Fundamental Difference: Inside-Out vs Outside-In
Understanding the distinction between Thanos and Vigilmon requires understanding where each tool sits in relation to your infrastructure.
Thanos is inside-out. It collects metrics emitted by your services, stores them in object storage, and lets you query across them. If your Kubernetes cluster reports healthy pods and your application metrics look normal, Thanos will reflect that. It has no way to know that a BGP route flap in a cloud provider's backbone made your application unreachable from Australia for 15 minutes — because no internal metric surface would capture that event.
Vigilmon is outside-in. It sits on the public internet and asks the same question a real user asks: "Can I reach this URL right now?" If your CDN misconfigures an edge cache, if a DNS record TTLs incorrectly after a migration, if your TLS certificate silently expires — Vigilmon catches it because it's probing from outside, exactly the way users experience your service.
These are complementary failure modes. Thanos tells you what your systems are doing internally. Vigilmon tells you whether users can reach your systems at all.
Who Uses Thanos?
Thanos is designed for teams operating large-scale Prometheus deployments:
- Platform and SRE teams at companies with 50+ microservices
- Multi-cluster Kubernetes environments where each cluster has its own Prometheus
- Organisations with compliance requirements for 1–5 year metrics retention
- Teams building cross-team or cross-region performance dashboards
- Data engineering teams needing efficient block storage and downsampling
Running Thanos in production is a non-trivial commitment. You'll operate at minimum a sidecar per Prometheus, a store gateway, and a query frontend. Object storage bucket IAM policies, compaction schedules, and query deduplication flags are all configuration surface area your team owns. This is the right trade-off for large-scale internal metrics — but it's overengineering for answering "is my website up?"
Who Uses Vigilmon?
Vigilmon serves any team that has public-facing endpoints they need to know are reachable:
- Startups and small teams that need professional-grade uptime monitoring without infrastructure overhead
- DevOps teams that want to know about outages before users email support
- SRE teams at larger companies who already run Thanos but need the outside-in perspective
- Developers monitoring scheduled cron jobs, webhooks, and API endpoints
- Teams with customer SLA commitments who need documented uptime records
Feature Comparison
| Feature | Thanos | Vigilmon | |---|---|---| | Long-term Prometheus metrics retention | ✅ core strength | ❌ | | Global query across Prometheus fleet | ✅ | ❌ | | External HTTP uptime monitoring | ❌ | ✅ built-in | | TCP port monitoring | ❌ | ✅ built-in | | Cron job heartbeat monitoring | ❌ | ✅ built-in | | Multi-region independent probing | ❌ | ✅ default | | Probes from outside your infrastructure | ❌ | ✅ always | | DNS failure detection | ❌ | ✅ | | CDN/TLS failure detection | ❌ | ✅ | | Status page for users | ❌ | ✅ included | | Self-hosted operation required | ✅ (complex) | ❌ SaaS | | Object storage integration | ✅ S3/GCS/Azure | ❌ | | PromQL query support | ✅ (via Thanos Query) | ❌ |
The Failure Mode Thanos Cannot See
Consider a real scenario: you push a DNS change that sets your apex domain's TTL to 5 minutes and accidentally removes the CNAME for www. Your Kubernetes pods are healthy. Your Prometheus metrics are nominal. Thanos's global query view shows green dashboards across every cluster.
Meanwhile, 40% of your users — those who type www.yourapp.com — are getting NXDOMAIN responses.
Thanos will never see this failure because DNS is resolved before the HTTP request reaches your services. Vigilmon will alert within minutes because its probes are making real HTTP requests from real public internet locations.
This is the class of failure that external monitoring catches and internal metrics systems structurally cannot.
Running Thanos and Vigilmon Together
The most complete production observability stack combines internal metrics (Prometheus + Thanos) with external uptime monitoring (Vigilmon):
- Thanos handles long-term retention of application and infrastructure metrics, cross-cluster querying, and capacity planning dashboards
- Vigilmon confirms that public endpoints are reachable, catches infrastructure-level failures invisible to internal metrics, and provides a status page for user communication during incidents
The two tools don't overlap. They answer different questions — and for any production service, both questions matter.
Summary
Thanos is an outstanding solution for teams that need to scale Prometheus across fleets of clusters with years of metrics retention. It solves real infrastructure problems at real scale.
Vigilmon is the answer to a different question: "Can our users reach us right now?" That's a question no amount of Prometheus federation can answer — because Prometheus scrapes from inside your network, and Vigilmon probes from outside.
Start external uptime monitoring for free at vigilmon.online — 5 monitors, 1-minute intervals, multi-region consensus alerting, and a status page included at $0/month.
Tags: #monitoring #devops #prometheus #thanos #uptime #sre #observability #metrics