Devops Watch Stack
devops_watch_stackIdempotent
Check the health of a named vendor stack — a saved list of vendors representing your infrastructure dependencies. On the first call, provide vendors to define the stack; subsequent calls can omit vendors to reuse the persisted list. Returns a unified health snapshot with an aggregate rollup plus per-vendor detail. A vendor that cannot be resolved or reached is reported in its own row and left out of the saved stack, so one bad entry never discards the sweep. Ideal for morning status checks or pre-deploy sweeps. Multiple stacks can coexist (e.g., "production", "staging").
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows. | summary |
| vendors | No | Vendor slugs (e.g., "github", "aws") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack. When omitted, uses the previously saved list for stack_name. | |
| stack_name | No | Name for this vendor stack. Defaults to "default". Use distinct names to manage multiple stacks (e.g., "production", "data-layer"). Letters, digits, hyphens, and underscores, optionally separated by single dots or slashes ("prod.eu", "team/prod"); 1-64 characters. No spaces or colons. | default |
| component_limit | No | Maximum components returned per vendor in detailed mode (1-500). Large status pages publish hundreds of components, so a full stack at a high limit returns a very large response; narrow with component_filter instead where possible. | |
| component_filter | No | Case-insensitive substring matched against component names in detailed mode (e.g., "api" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode. |
Output Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cap | No | The per-vendor component_limit that was applied. Present only when truncated. | |
| error | No | Present when the call failed. Absent on success. | |
| shown | No | Components returned across the stack. Present only when truncated. | |
| health | No | Aggregate health rollup: all_operational = everything clear, maintenance = at least one vendor in a scheduled window and nothing worse open, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage, unknown = at least one vendor could not be checked (unresolvable entry, blocked target, or failed fetch) and no checked vendor reported a worse issue. Never all_operational when any vendor errored or is in a window. | |
| notice | No | Plain-language explanation of the capped component lists — how many components were omitted and how to reach them (component_filter to target one, component_limit to raise the cap). Present only when truncated. | |
| summary | No | Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + maintenance + unavailable = total. | |
| vendors | No | Per-vendor status results. | |
| truncated | No | True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped. | |
| checked_at | No | ISO 8601 UTC timestamp of this check. | |
| stack_name | No | Name of the stack checked. | |
| totalCount | No | Components matching component_filter across the stack before the cap. Present only when truncated. | |
| omitted_vendors | No | Entries that could not be resolved or whose URL was blocked; they still appear in vendors[] with an error. A call that saved the stack left them out of the write; a call that reused a saved stack leaves them in it until you re-provide the vendors list. Empty when every entry resolved. | |
| stack_persisted | No | True when the vendor list was saved to state on this call. Only the vendors that resolved are saved — see omitted_vendors. |