Cortex is a powerful solution for scaling Prometheus to enterprise dimensions — but uptime monitoring is not what it does. This comparison explains what Cortex is built for, where it ends, and why teams running Cortex at scale still need Vigilmon for external availability checks.
What Is Cortex?
Cortex is an open-source, horizontally scalable, multi-tenant, long-term storage backend for Prometheus metrics. Originally developed by Weaveworks and Grafana Labs, it is now a CNCF incubating project.
Cortex is designed to solve the operational challenges that organisations encounter once a single Prometheus instance is no longer sufficient:
- Horizontal scalability: Individual Cortex components (ingester, querier, compactor, store-gateway) scale independently. You can handle billions of active time series by adding nodes — not by running bigger machines.
- Multi-tenancy: Cortex partitions data by tenant ID, allowing a single Cortex cluster to serve multiple teams or customers in isolation, with per-tenant retention policies and query limits.
- Long-term retention: Cortex stores data in object storage (S3, GCS, Azure Blob) with configurable retention — from weeks to years — at a fraction of the cost of local NVMe storage.
- PromQL compatibility: Applications that query Prometheus via PromQL work against Cortex without changes. It presents a Prometheus-compatible HTTP API.
- Grafana integration: Cortex is a first-class Grafana data source. Teams using Grafana dashboards can point them at Cortex without modification.
Running Cortex in production means operating a distributed system with multiple stateful and stateless tiers. The operational investment is significant — Cortex is the choice when Prometheus's single-instance limits have genuinely been hit.
What Is Vigilmon?
Vigilmon is a SaaS external uptime monitoring service. Instead of collecting metrics from inside your infrastructure, Vigilmon probes your endpoints from independent locations on the public internet, then alerts your team when services become unreachable.
Vigilmon's core capabilities include:
- HTTP/HTTPS endpoint monitoring with status code and response body validation
- TCP port monitoring for databases, mail servers, and other non-HTTP services
- Cron job heartbeat monitoring (alerts when a scheduled job goes silent)
- Multi-region consensus — only alerts when probes from multiple regions agree the target is down
- Response time history with configurable time windows
- Alert delivery via Slack, webhook, and email
- Public-facing status page for user communication during incidents
No components to deploy, no object storage bucket to configure, no ingester ring to manage. Vigilmon is operational in two minutes.
Metrics Storage vs Active Probing: A Fundamental Distinction
Cortex and Vigilmon serve fundamentally different purposes, and understanding that distinction is the key to evaluating them.
Cortex is a passive metrics store. Your services expose Prometheus-format /metrics endpoints. Prometheus scrapes them on an interval and remote-writes the results into Cortex. Cortex stores, indexes, and serves this data. Every data point in Cortex originated inside your infrastructure — it was generated by a process you operate.
This means Cortex has no visibility into failures that occur between your infrastructure and your users:
- A CDN edge node serving incorrect cached responses
- A DNS misconfiguration after a domain transfer
- An expired TLS certificate that browsers reject but internal health checks don't detect
- An upstream transit provider experiencing packet loss that affects only external traffic
- A geo-targeted routing failure that affects users in a specific region
These failures don't generate a Prometheus metric. Your services are running, your scrapers are succeeding, and Cortex is happily ingesting time series — but users are getting errors.
Vigilmon is an active prober. It constructs real HTTP requests and sends them from multiple independent locations on the public internet. It doesn't care what your internal metrics look like. It only cares whether the response came back with the right status code within the timeout window. If it didn't — from multiple regions — it alerts.
Complexity and Cost: A Real Trade-Off
Cortex is architected for scale — which means it brings scale-level complexity. A minimal production Cortex deployment includes:
- Ingesters (stateful; require consistent hashing ring, graceful shutdown procedures)
- Distributors (route incoming write requests to ingesters)
- Queriers (fan out read requests across ingesters and store-gateway)
- Store-gateway (serves historical blocks from object storage)
- Compactor (merges and downsamples blocks)
- Ruler (evaluates recording rules and alerts)
- Object storage (S3, GCS, or Azure Blob — and the IAM policies that protect it)
- Etcd or Consul (for ring membership in some configurations)
Operating this stack requires dedicated platform engineering effort. You'll manage rolling upgrades, ring rebalancing, compaction scheduling, and retention policies. The return on that investment is enormous if you're managing thousands of microservices, dozens of teams, and petabytes of metrics — but it's severe over-engineering for confirming that your API is reachable from the internet.
Vigilmon's operational cost is zero. There are no servers, no rings, no object buckets, and no on-call rotations for the monitoring system itself. If Vigilmon goes down, Vigilmon alerts you — your monitoring isn't a single point of failure you have to monitor separately.
Feature Comparison
| Feature | Cortex | Vigilmon | |---|---|---| | Horizontally scalable Prometheus storage | ✅ core strength | ❌ | | Multi-tenant metrics backend | ✅ | ❌ | | PromQL query compatibility | ✅ | ❌ | | Long-term retention (years) | ✅ | ❌ | | External HTTP/HTTPS uptime monitoring | ❌ | ✅ built-in | | TCP port monitoring | ❌ | ✅ built-in | | Cron job heartbeat monitoring | ❌ | ✅ built-in | | Multi-region independent probing | ❌ | ✅ default | | DNS and TLS failure detection | ❌ | ✅ | | Status page for users | ❌ | ✅ included | | Self-hosted infrastructure required | ✅ (complex cluster) | ❌ SaaS | | Setup time | Days to weeks | ~2 minutes | | Operational overhead | High | None |
Who Uses Cortex?
Cortex is deployed by large engineering organisations facing genuine Prometheus scalability limits:
- Companies operating 100+ microservices with separate Prometheus instances per team
- Organisations building multi-tenant monitoring platforms (e.g., managed Kubernetes providers)
- Teams with compliance requirements for multi-year metrics retention
- Platform teams building internal metrics-as-a-service offerings for their engineering organisation
Cortex is not a starting point — it's where you arrive after outgrowing Thanos, single-Prometheus federation, or managed Prometheus offerings. The teams running Cortex in production are typically employing dedicated platform engineers whose primary responsibility is the observability stack.
Who Uses Vigilmon?
Vigilmon is for any team with public-facing services that need to know when users can't reach them:
- Early-stage teams who need professional uptime monitoring without the infrastructure burden
- Engineering teams that already run Cortex for internal metrics but need external availability confirmation
- DevOps engineers monitoring webhook endpoints, scheduled jobs, and third-party integrations
- Product teams with SLA commitments who need verifiable uptime records
- Teams that want to know about an outage before users report it on social media
Using Cortex and Vigilmon Together
For large engineering organisations, Cortex and Vigilmon are complementary layers of an observability stack:
- Cortex stores years of application and infrastructure metrics, serves cross-team PromQL queries, and powers Grafana dashboards for capacity planning and SLO tracking
- Vigilmon probes public endpoints from outside your network, catches failures invisible to internal metrics, and provides a status page for user communication during incidents
An outage that Cortex dashboards show as healthy but Vigilmon catches is the most critical type of failure to detect: it means something between your services and your users has broken — CDN, DNS, TLS, upstream routing — while your internal systems report nominal behaviour.
Summary
Cortex is one of the most capable Prometheus-compatible metrics backends available. If your organisation has outgrown single-instance Prometheus and needs multi-tenant, petabyte-scale, long-term metrics storage with PromQL compatibility, Cortex is an excellent choice.
Vigilmon solves a different problem: confirming that your public endpoints are reachable from the internet, right now, from multiple independent locations. No amount of horizontally scaled metrics storage answers that question — because the question is about outside-in availability, not inside-out metrics collection.
Start external uptime monitoring for free at vigilmon.online — 5 monitors, 1-minute intervals, multi-region consensus alerting, and a user-facing status page at $0/month.
Tags: #monitoring #devops #prometheus #cortex #uptime #sre #metrics #observability