Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Understand the current alerts surface and what actionability to expect from it today.

​
Prerequisites

  • An environment with enough runtime activity to generate alerts

​
Workflow

1
Review active alerts first, then drill into the associated resource.
2
Use severity and scope as triage filters.
3
Treat alerting as helpful but not yet the full replacement for operational judgment.

​
How the alerts view is organized

  • Severity filters separate warning from critical issues.
  • Status filters separate active from resolved alerts.
  • Scope filters let you narrow the feed to projects, stacks, databases, or nodes.

​
Severity levels

  • info: informational, no action needed.
  • warning: something is off and worth a look.
  • critical: needs immediate attention.

​
What to expect today

Alerts are derived from runtime health and events so you can focus on active problems instead of scanning every resource. Treat them as triage help, not a full external paging system — when an alert fires, drill into the associated resource for the real evidence.

​
Expected result

You can tell which issues need immediate attention and which are informational.

Operations overview

The operations area is the cross-resource health and runtime visibility surface for StackShift.

Recovery states, logs, and troubleshooting

Read the operation state on a resource — its status, current step, attempt count, retryable flag, and last error — together with logs, instead of treating a single “error” badge as the whole story.

Services view

Track stack-backed services and databases in one place with health, backup posture, and upgrade cues.