Works with your existing observability stack
Kubestead reads from the metrics tools you already run. No new agents. No parallel data pipeline. Kubestead is not a monitoring tool — it is a deployment decision engine that reads the monitoring data you already have.
Metrics Sources
Kubestead reads metric queries directly from your existing observability endpoint. No data is copied, cached, or transmitted to Kubestead servers — only threshold evaluation results leave your cluster. Prometheus and Datadog are available on all plans. Grafana Mimir, VictoriaMetrics, New Relic, and InfluxDB require Team or Platform.
Notifications
Rollback events and canary promotions can route to multiple notification targets simultaneously. Rollback notifications include the offending metric name, the threshold value, and the measured value at the moment of the decision — not just "deployment failed."
GitOps / CD
RolloutPolicy manifests are standard Kubernetes CRDs. Commit them to your repository alongside your service manifests and let your existing CD pipeline sync them into the cluster. No separate Kubestead deploy step required.
Service Mesh (optional)
Service mesh is not required. Kubestead uses Kubernetes replica-count traffic splitting by default, which works for most teams. If you need sub-percentage canary slices or header-based traffic routing, connect your Istio, Linkerd, or Envoy Gateway layer for weighted routing.
Don't see your tool?
RolloutPolicy supports arbitrary PromQL, Datadog query strings, and New Relic NRQL. If your observability platform exposes a queryable HTTP API, Kubestead can evaluate it as a canary gate. Tell us what you're running — we evaluate integration requests against our roadmap.