Work with findings
Change a finding's status, have Sentinel analyse it with the resource's logs, and report a suspected Stackship bug.
Requires: sentinel/write
Open a finding from the Findings tab of the Sentinel page, from Active alerts, or from a
resource's Sentinel card. Changing a finding and starting an analysis need sentinel/write in the
boundary; without it the buttons are not shown.
Change the status
Choose Change status and pick one of Open, Acknowledged, Resolved, Manually resolved, False positive or Won't fix — see Statuses.
- Mark a problem you are working on Acknowledged. It stays active, and closes by itself once Sentinel stops seeing it.
- Marking a finding Resolved or Manually resolved while the problem is still there does not last: the next run or rule check that sees it opens it again.
- False positive and Won't fix stay as you set them, however often the problem is seen again.
Analyse a finding with logs
For a finding about an app, a static web app or a container instance, the finding has a Log
analysis card with Analyze with logs. You need, besides sentinel/write, permission to read
that resource's logs — the same one its Logs tab needs.
- Choose Analyze with logs. Sentinel reads the last lines — 200 by default — of each container in the resource's pods; for a container that has crashed, it reads those of the instance that crashed. It reads with your permissions, for at most 15 seconds.
- The lines are redacted and sent, with the finding's evidence, to the language model the platform uses for Sentinel.
- When the answer arrives, What's happening, Impact, How to fix it and How to Verify are replaced by the model's explanation, and the log lines appear under Technical details as evidence.
The card says when the finding was last analysed, whether an analysis is running, and whether the last one failed. The explanation stays while the problem lasts; if the finding closes and later reopens, it starts from Sentinel's own text again.
| Message | Cause |
|---|---|
| You don't have permission to read this resource's logs | You lack the resource's log permission |
| The resource has no pods to read logs from. Start it and try again. | Nothing is running |
| An analysis is already running for this finding. | Only one runs per finding at a time |
| This finding isn't tied to a resource whose logs Sentinel can read. | Not an app, static web app or container instance |
Important
The log lines stay on the finding, where everyone who can read the boundary's findings can read them — including people who may not read the resource's logs. Analyse only when that is acceptable for what the resource logs.
Report a Stackship bug
When Sentinel suspects that Stackship itself is at fault, the finding has a Looks like a Stackship bug section with Sentinel's reason and a list under Include this in your report: the finding's id and fingerprint, the resource, the boundary, the severity, when it was first and last seen, and how often.
If your installation has bug reporting turned on, Report to Stackship opens Report a bug
with Area set to Sentinel, the title Sentinel: <finding title>, and a description made of the
reason and that list. Edit what you like and choose Submit report. The report sends the area,
title and description, the address of the page you are on, and your e-mail address from your
sign-in; it becomes an issue in the issue tracker your installation sends bug reports to, and the
confirmation names it. Nothing else from the finding — no evidence, no log lines — is sent.
Without the button, pass the listed details on to Stackship Support.
With the CLI
stsh sentinel findings --boundary my-boundary --filter status=Open
stsh sentinel findings <finding-id> --boundary my-boundary
stsh sentinel findings <finding-id> --status Acknowledged --boundary my-boundary--status takes Open, Acknowledged, Resolved, ManuallyResolved, FalsePositive or
WontFix.