Metric, log, and uptime monitoring, running on your side of the wall.
Metric monitors from a built-in catalog for what you already collect, real-time log monitoring with zero ingestion, and uptime checks on your endpoints, all executing locally, so alerts keep firing even if Randoli's control plane is unavailable.
Spin up from a built-in catalog in seconds, or write your own in PromQL for anything the catalog doesn't cover.
Real-time log monitoring with no ingestion step: fast, cost-efficient, and the underlying log data never leaves your environment.
Continuous checks against your API endpoints, with an uptime visualization and error surfacing the moment a check fails.
Built-in monitors for what already runs in your cluster.
The metric monitor catalog ships with pre-built coverage, so most teams don't need to write PromQL on day one. Beyond the catalog, any metric you bring in via OpenTelemetry, standard or custom, can be monitored the same way.
Real-time coverage. Zero ingestion bill. Nothing leaves your cluster.
Log monitors run against logs processed locally, streamed through the same real-time pipeline as every other signal, not a delayed batch job with its own price tag.
The underlying log data stays in your environment. Only the alert crosses the wire.
Live today across Kubernetes and VMs. See the full coverage roadmap on Observability for Kubernetes.
Monitoring and alerting don't depend on Randoli being reachable.
All monitor evaluation happens locally, on your side of the wall. Metric monitors, log monitors, and uptime checks all execute and alert from within your environment, so if the Randoli control plane is temporarily unavailable, monitoring and alerting keep working. It's the same federated control plane principle behind the rest of the platform: your data, and now your alerting, stays put.