When something goes wrong, you want to see three things: what the application is writing right now, how heavily it was loaded and whether it is reachable from outside. Clusterward shows all of it on every service – logs from all instances, CPU and memory over 30 days, and uptime checks with alerts. No agent in the cluster and no Grafana setup.
Kubernetes monitoring in Clusterward consists of three parts on the service: a log viewer that merges the output of all instances by time, a usage history for CPU, memory and instances that Clusterward records itself every minute, and uptime checks that test your domains from outside. If something fails, notifications speak up – and the link takes you straight to the logs.
An uptime check fails twice or a deployment fails – the message goes to your channels.
One click in the activity indicator opens the logs; after a crash, straight to the previous run.
Search, show errors only, pick a time range, look at usage alongside.
Increase memory, restart or restore an earlier version.
What you need first during an incident, right on the service in question.
The output of all instances of a service, merged by time, with a marker showing which instance each line came from. Or a single instance on its own.
The last 500 lines, 15 minutes, one hour, 6 or 24 hours – up to 10,000 lines, smooth to scroll. Or follow along live.
Matches are highlighted and you jump from one to the next. “Errors only” hides everything else.
If a container crashed and restarted, Clusterward shows the logs of the crashed run – that is usually where the cause is.
CPU and memory as a share of the limit, plus the instances, recorded every minute, from 15 minutes to 30 days. The request as a line, restarts as markers, and a click opens the chart large with current, average and peak values – for Helm services too.
Tests a domain of the service over HTTPS, with a path and expected status. Availability over 24 hours and 7 days, plus the average response time.
Two consecutive failures report the site as down, the first success afterward as back up. Once per event, not as a flood.
The selected time range as a .log file, to pass on to developers or support.
A failed check stays in the cockpit’s activity indicator until it responds again.
Logs come straight from the pods via the Kubernetes API – nothing is installed in the cluster.
CPU and memory come from the cluster’s metrics-server; without it, Clusterward records the instances.
Checks send a GET over HTTPS, do not follow redirects and treat certificate errors as an outage.
Alerts go out through notifications: Slack, Teams, webhook or email.
Clusterward stores usage and check results itself; it reads logs live from the cluster.
| Data | Resolution | How long |
|---|---|---|
| Logs | Every line | As long as the pod lives (last and previous run) |
| Usage, 24 hours | Per minute | 24 hours |
| Usage, 7 days | Per 10 minutes | 7 days |
| Usage, 30 days | Per hour | 30 days |
| Uptime results | Every check | 7 days |
| Notifications | Every message | 30 days in the delivery log |
Where alerts go and which events report in is set under Notifications. How a failed rollout is detected and how you return to an earlier version is covered under Deployments.
What the overview means for technical leadership is described in For CTOs; what evidence the logs provide for an audit, in Audit & NIS2.
What kubectl can do, where it stops and when your own stack pays off is described in Logs, usage and uptime without your own monitoring stack; how to get back after a faulty release, in Rollbacks on Kubernetes: why a tag is not a version.
Webhook, Slack, Teams or email – once per event.
Go to NotificationsGit, container image or Helm chart – rolled out with a health check.
Go to DeploymentsPredictable costs, no single point of knowledge, no lock-in.
Go to For CTOsCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionWe make a service crash, find the cause in the previous run and set up an uptime check with alerts in your Slack.
