Honest comparison

Sentinel vs Prometheus

Prometheus is a metrics database you query. Sentinel is an alerting layer you install. A lot of teams reach for the first because they wanted the second.

Start free → Read the docs

The honest version

Prometheus is the right answer to a large class of problems, and it is free. If you need arbitrary queries over historical metrics, SLO burn rates, or monitoring that keeps working when an external vendor does not, run Prometheus — Sentinel replaces none of that. This page is for the other case: the cluster where the metrics stack would be bigger than the workloads it watches, and where the realistic alternative to Sentinel is not Prometheus, it is nothing at all.

Side by side

No asterisks, and no rows invented to make one column look better.

Getting started
Prometheus — Helm chart, persistent storage, retention policy, Alertmanager config
Sentinel — One Helm release and one annotation
What you can ask it
Prometheus — Any metric, any time range, in PromQL
Sentinel — Up, degraded or down — no query language
History
Prometheus — As long as you provision disk for
Sentinel — 7 to 90 days of health signals, depending on plan
Alert delivery
Prometheus — Alertmanager — routing, inhibition and silences, in YAML
Sentinel — Retries with backoff, per-incident cooldown, circuit breaker, maintenance windows — in the UI
Noise during deploys
Prometheus — You tune a for: duration and hope
Sentinel — Rollout-aware — muted on a deliberate spec change, never on a node failure
Public status page
Prometheus — Not included
Sentinel — Included from the Pro plan
Who operates it
Prometheus — You — it is a stateful service with its own failure modes
Sentinel — Nobody. One stateless pod, 10m CPU, 32Mi

So which one should you pick?

Stay on Prometheus if

  • You genuinely query metrics — latency percentiles, saturation, custom SLO burn rates.
  • You already run it and somebody maintains it without resenting it.
  • Your monitoring has to survive the loss of any external vendor.

Try Sentinel if

  • You want alerts this afternoon, not a project on next quarter's roadmap.
  • Your alerting stack has quietly become bigger than the cluster it watches.
  • You want uptime history and a status page without assembling three tools.

Or run both

These are not mutually exclusive, and the combination is the most common setup. Add a webhook receiver to alertmanager.yml and your Prometheus rules become services in Sentinel — with the routing, the uptime history and the status page on top. Not a single metric leaves your cluster.

alertmanager.yml

receivers:
  - name: sentinel
    webhook_configs:
      - url: https://app.sentinel-app.io/api/v1/signals/alertmanager?service_label=app
        http_config:
          basic_auth:
            username: YOUR_KEY_ID
            password: YOUR_SECRET

Questions people actually ask

Does Sentinel store metrics?

No. It stores health signals — a service, an up or down status, a timestamp and optional metadata. That is why it needs no time-series database, and why the price does not move when your traffic does.

Can I run Sentinel and Prometheus together?

Yes. Point Alertmanager at Sentinel as a webhook receiver: Prometheus keeps doing detection, Sentinel handles delivery, uptime history and the public status page.

How does it avoid alerting on every deploy?

The operator watches metadata.generation, which Kubernetes only bumps when the spec changes. Degraded alerts are muted during a deliberate rollout — but a node failure, an OOMKill or a deleted pod never touch the generation, so those still page immediately.

Other comparisons

Sentinel vs Uptime Kuma → Sentinel vs Datadog →

Simple, transparent pricing

Free to get started. Scale as you grow.

View plans →