What comes with a problem: the context pack
Every problem notification carries a context pack: what else is true around the problem, gathered from what SZ-MCP already holds at the moment it is sent. It covers where the device is, what it hangs off, other problems nearby, recent events and changes, how its metrics compare with a usual week, and how often this happened before. No AI model writes it and no controller call is made.
The pack goes with PROBLEM and ESCALATION notifications, not with recoveries or acknowledgements. Gathering it is best effort: if it fails, the notification goes out without it rather than not at all.
What is in the pack?
Section titled “What is in the pack?”Up to seven parts, each left out when there is nothing to say:
| Part | What it holds |
|---|---|
| Where | The device’s containers and location, outermost first (domain › zone › AP group, or a hall) |
| Upstream | What it physically hangs off, such as an AP’s switch port and switch, with each one’s status (up to 3) |
| Also now (related) | Other current problems on the same device, on its upstream, on something with the same upstream, or in the same nearest container (“three APs in one zone down”), with the reason for each. The count, then up to 5 |
| Events | The controller’s events and alarms on the device and its upstream in the last 2 hours. The count, then the newest 5 |
| Changes | Admin changes on the controller, configuration drift, inventory changes and writes through SZ-MCP on the device, what contains it, its location and its upstream, in the last 24 hours. The count, then the newest 5 |
| Usual | Its metrics against their weekly baseline for this hour of the week, unusual ones first (up to 6). Left out until a baseline has 3 weeks of data |
| Before | How many earlier episodes of this rule on this instance (HARD, then recovered) there were in the last 30 days, and when the last one started and how long it lasted |
In email it reads like this:
Context: Where: <domain> › <zone> › <AP group> Upstream: <type> <name> (<status>) Also now: <N> other problems nearby <rule> <state> on <name> (<why>) Events: <N> in the last 120 min <HH:MM> <event text> Changes: <N> in the last 24 h <MM-DD HH:MM> <source> <who>: <what> Usual: for <Tue 10:00 UTC> <name> <metric> <value> <unit>, usually <usual> (<verdict>) Before: <N> times in 30 days, last <date time> for <M> minHow does each channel show it?
Section titled “How does each channel show it?”| Where | What it shows |
|---|---|
| The whole pack, as above | |
| Jira | The whole pack, in the issue description or comment |
| Signed JSON webhook | The pack as a context object on the notification |
| Slack and Microsoft Teams | Only the Where line |
| PagerDuty | The pack as text in the alert’s custom details |
| ServiceNow | The whole pack, in the incident description |
| Alerts page | The problem drawer shows Where, Upstream, Related, Changes, Events, Against usual and Before, the lists cut to their first few |
The rule’s runbook and the site’s notes come with the pack; see Site notes and runbooks.
Can Claude read the same thing?
Section titled “Can Claude read the same thing?”Yes: alerts.context returns the pack for current problems, and any role
can call it. Ask “What’s going on around the ap-offline problem on
Hall-B-AP-2?”
| Argument | Meaning |
|---|---|
rule, instance, entity | Which current problems to bundle, in any combination; entity takes an id or a bare MAC. At least one is needed |
limit | Problems to bundle: 5 by default, up to 20 |
at | Gather events, changes and baselines as of this time (ISO or epoch ms) instead of now |
With only entity and no current problem on it, Claude gets the pack for the
device as it is now. One call builds at most 25 packs; in a big outage the
first problems get theirs and the rest tell the same story. Post-mortems use
the pack as it was when the problem went HARD.