Kubernetes monitoring without your own monitoring stack

• Do I have to install anything in the cluster?

  No. Clusterward reads logs through the Kubernetes API and usage through the cluster’s metrics-server, and the uptime checks run from Clusterward. Without metrics-server, Clusterward only records the number of instances.

• How long are logs kept?

  As long as the pod exists: the current run and, after a crash, the previous one. Clusterward does not store logs permanently. If you need logs over weeks, download a time range as a file or use a central logging system in addition.

• Why can’t I see the cause of a crash in the current log?

  Because the restarted container starts a fresh log. Tick the “Previous run” checkbox in the log viewer – Clusterward then shows the output of the crashed container, usually with the error message at the end.

• Can I see the load of all clusters at a glance?

  Yes, under Infrastructure → Monitoring: one card per Scaleway project with its clusters (CPU and memory, used and requested), every node, the managed database instances with CPU, memory, connections and disk, and the load balancers with their public address. The cards are re-read every 15 seconds; a badge at the top of each card names the worst thing in it, such as a node that is not ready. The page only needs the view permission for Operations.

• Where do I see all services and uptime checks at once?

  Under Infrastructure → Monitoring. “Services” lists every deployed service with CPU, memory and restarts over the last 24 hours, the ones closest to a limit first, with its instances one click away. “Uptime” shows every check with its 24-hour bar, availability and response time, down and slow ones first – plus the services nobody watches yet.

• Can an AI assistant analyse logs and usage?

  Yes, if you allow it. A connected assistant reads usage, uptime checks and the last 24 hours, logs only with the switch of their own, “Also service logs”. Ready-made prompts such as uptime report or capacity review sum it up in one answer.

• What exactly does an uptime check test?

  A GET over HTTPS to a domain of the service, with the path of your choice, for example / or /up. A response below 400, or exactly the status you expect, counts as up. A timeout after 10 seconds or a certificate error counts as an outage.

• When do I get an alert?

  After two consecutive failures, Clusterward reports the site to your channels as down, and after the first success as back up. You define which channels those are under Notifications.

• Do the checks run from multiple regions?

  No, from one region: wherever Clusterward runs. A check tells you that the site is not responding for anyone who reaches it by the same route – not whether it is down in every region of the world.

• What do the dashed lines in the usage chart mean?

  The gray line is the service’s request, the red one its limit, each multiplied by the running instances. If memory runs along the limit and restarts pile up, the service is short on memory.

• Does this replace Prometheus and Grafana?

  For the question “is my service running, and how heavily was it loaded”, usually yes. Custom application metrics, dashboards across many services and logs over months remain the strength of your own monitoring stack.

• Do my customers get a status page?

  The uptime checks on a service report outages to your team. A public status page for your customers comes with Uptime Kuma from the app catalog: a monitor of its own in your cluster, set up with a name, a domain and the cluster, that also checks services outside Clusterward.

Can’t find your question? Write to us – we usually reply on the same business day.