How monitoring works

There are two kinds of monitoring on gh0stcloud, and they are deliberately separate.

We monitor the platform so that it keeps running: clusters, networking, storage, the services underneath. That is our operational tooling and not something you see.

You monitor your application, because only you know what it behaving correctly looks like. For that you get your own metrics and logs, separated from every other customer's, under your own credentials.

That separation is why we do not need to look inside your application data in order to operate the platform.

Where to find what

Quick state lives in the portal: is your application running, did the last change arrive, is the route ready, how is storage doing. For most questions that is enough.

When you need to go deeper (individual log lines, metrics over time, the path of a request), you get a dedicated interface for it. It is not started by default; you enable it in the portal under Managed Applications. After that your AI assistant can reach it too, and tell you what your application is actually doing rather than only what you asked for.

What this is not

These views show you your application. They are not a commitment that every internal metric, log line and platform signal is handed out. Much of that belongs to systems shared between customers, and is therefore not something we can show.

What is available also depends on your plan and on the scope of operations you have agreed.

What actually helps fastest

Metrics rarely answer why something broke. They tell you when. The answer to why is almost always sitting next to it: in your Git history, in the last change made in the portal, or in a platform status notice.

So when you see a spike in a graph, the next useful question is not "which other metric" but "what happened at that time".