View alerts

Seeing alerts needs monitoring/read on the resource, or on the boundary for the boundary-wide list. Reader, Contributor, Owner, the platform roles and every scoped reader and operator role hold it.

On a resource's page

Active alerts is a card at the top of the resource's Overview, above everything else. It is only there while the resource has an alert firing. It lists the firing alerts, most severe first, each with its name, description, the time it was triggered and its level.

The Alerts tab, under Monitoring in the page's tabs, appears once the resource has raised an alert that is still kept. It lists the firing alerts first, most severe first, then the resolved ones, newest first:

• Active or Resolved, and the level;
• the description, for example which container, and how close it is to its limit;
• Triggered and the time, or the time it was triggered and the time it resolved.

It shows at most 50 alerts. An S3 storage account's Overview has no Active alerts card; its Alerts tab works the same way. Alerts about an app's slots appear on the app's page, because a slot's pods are judged as part of the app.

Without monitoring/read, neither the card nor the tab is shown.

With the CLI

stsh monitor alerts
stsh monitor alerts -b my-boundary -o json

The command lists the alerts firing now in the boundary, across all its resource groups, newest first. The table's Severity and State columns stay empty in this version; -o json shows every field, including level and isActive.

Through the API

{type} is the resource type as it appears in the resource's own routes, such as apps or postgresclusters. For example:

stsh api GET "/boundaries/<boundary-id>/resourcegroups/my-rg/resources/monitoring/apps/my-app/alerts?includeResolved=true"

Each alert carries: