Monitoring & alerts
Two honest statements first. A test cluster has no monitoring stack — that is part of why it costs €49. And on any cluster, the platform does not read your application’s logs or data; what it watches is the cluster, not what runs in it.
Every cluster: health in the console
Section titled “Every cluster: health in the console”The console shows, for every cluster and at every moment:
- the four health conditions Gardener maintains — API server reachable, control plane healthy, every node ready, system components healthy — with the reason when one is not;
- the last operation (create, reconcile, maintenance, hibernate) with its state and progress;
- warnings before they bite: a version about to expire, a certificate nearing its date, a webhook that would block a wake-up;
- the activity log: who changed what, when.
This view is served from the platform, not from your cluster, so it stays useful when the cluster is the thing that is down. It shows the last known state and that it stopped.
Production clusters: a monitoring stack
Section titled “Production clusters: a monitoring stack”A production cluster carries a monitoring stack next to its control plane — Prometheus and dashboards — that the platform uses to operate it: API-server latency and availability, node and pod counts, capacity, etcd health. It is what lets us see a problem before you do.
Two ways to use it yourself:
- Federate the cluster’s control-plane metrics into your own Prometheus, Grafana or SaaS monitoring. Ask support for the federation endpoint and its credential; it is scoped to your cluster.
- Scrape inside the cluster. Node and workload metrics are yours anyway: run your own Prometheus in the cluster like on any Kubernetes cluster you administer.
One caveat worth stating: control-plane metrics you federate into a Prometheus inside the same cluster do not survive that cluster being down. Keep the copy you care about outside.
Private clusters: the gateway’s metrics
Section titled “Private clusters: the gateway’s metrics”On a private cluster, the NAT gateway exports its own metrics — up, NAT throughput, connection-table usage, denied and allowed outbound packets, allow-list state — on its private address. A production cluster’s monitoring stack scrapes them and carries alert rules for a gateway that is down, a firewall that is not enforcing, a connection table above 80 %, denials, and a stale allow-list. Any Prometheus you run inside the cluster can scrape the same endpoint. You can also open the metrics endpoint to an external poller behind TLS and basic auth, from networks you list.
Alerts
Section titled “Alerts”Alerts for your cluster reach your team by email, to the addresses you enter for the cluster. Gardener sends email only; a Slack or PagerDuty route is something you bridge from your own Prometheus. Alerts require the monitoring stack, so they are a production-cluster feature.
The platform keeps the cluster’s events and its activity log. It does not aggregate your pods’ logs. On a private cluster the gateway’s firewall and flow logs are forwarded to a collector you name inside your own network — they never reach the platform, which keeps counts only.
What a test cluster does not have
Section titled “What a test cluster does not have”No Prometheus, no dashboards, no email alerts. The console’s health view is all there is, and it is enough for dev, staging and CI. If you need alerting on a cluster, make it a production cluster.