Skip to content
Stackship documentation Svenska

SentinelUsers

Sentinel

Sentinel watches the workloads in your boundary, explains in plain language what is wrong with them, and tells you what to do about it.

Sentinel looks at the workloads in every boundary, notices what is failing or at risk, and records each problem as a finding. A finding is written for someone who does not know Kubernetes: what is happening, what it will cause, the steps to fix it, and who to contact when the fix is not yours to make.

Where findings come from

  • Rules. Every two minutes by default, Sentinel checks the boundary's pods for well-known failures — containers running out of memory, crash loops, images that cannot be pulled, pods with no room to run — and records them at once, without any language model.
  • Analysis runs. Every 30 minutes by default, Sentinel gathers what it can see about each boundary — pod and workload state, Kubernetes warning events, the platform's active alerts and, where the platform records them, blocked network connections — and has a language model explain it. The model writes findings about security, performance, reliability and code. Runs need a language model registered on the platform; without one, only the rules produce findings.
  • On request. Someone who can change findings and read an app's, static web app's or container instance's logs can have Sentinel re-examine a finding about it together with those logs.

How this works, and what is sent to the language model, is described in How Sentinel works.

What you see

Open Sentinel under Quick Access in the portal's sidebar. It shows the boundary you have selected: an overview, the list of findings, and the history of runs. Findings about one resource are also shown on that resource's page. Platform administrators also see findings about the platform itself.

A finding closes on its own when Sentinel stops seeing the problem. You can also acknowledge it, mark it fixed, or dismiss it as a false positive or as something you will not fix.

Pages