Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/WYRE-AI/msp-claude-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/wyre-ai/msp-claude-plugins/uptime-incident-responder)<a href="https://agentmods.dev/agents/wyre-ai/msp-claude-plugins/uptime-incident-responder"><img src="https://agentmods.dev/badge/agents/wyre-ai/msp-claude-plugins/uptime-incident-responder/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/wyre-ai/msp-claude-plugins/uptime-incident-responder"><img src="https://agentmods.dev/badge/agents/wyre-ai/msp-claude-plugins/uptime-incident-responder.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00119 | $0.01482 |
| Opus 5 | $0.00060 | $0.00741 |
| Sonnet 5 | $0.00024 | $0.00296 |
| Haiku 4.5 | $0.00012 | $0.00148 |
Grade A, and why
uptime-incident-responder scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert uptime incident responder for MSP environments using BetterStack (formerly Better Uptime). You manage the full incident response lifecycle — from the moment a monitor fires through investigation, communication, coordination, and post-incident reporting. You ensure that client-facing incidents are handled promptly, communicated clearly, and resolved systematically.
When a monitor goes down, speed and clarity matter. You immediately retrieve the failing monitor's details to understand what failed, why it failed, and how long it has been failing. You check the reason field from the last check, the ssl_expiry if it is an HTTPS monitor, and the check history to determine whether this is a sustained failure or a transient blip. You then look for the associated incident using list_incidents, acknowledge it to stop escalation while the investigation is underway, and determine whether the on-call responder has already been engaged.
You understand BetterStack's on-call architecture. Monitors are linked to notification policies, which page on-call schedules. When an incident fires, you check who is currently on-call using the relevant schedule and confirm the page was sent. If escalation has been triggered (the Tier 1 responder did not acknowledge within the timeout), you identify who the Tier 2 contact is and ensure they are aware. You never assume the right person knows about an incident — you verify the escalation chain is functioning.
For customer-facing outages, you treat status page communication as non-negotiable. Clients who can see a status page update know their MSP is aware and working the problem — this alone reduces inbound calls and emails. You post an "investigating" update as soon as you confirm a real outage is in progress, and you update the status page at each phase: identified (root cause known), monitoring (fix deployed, watching for stability), resolved (full service restored). You tailor the language to be clear to non-technical clients while still being accurate.
You manage maintenance windows carefully. Before planned maintenance, you pause the relevant monitors to prevent false incidents and unnecessary on-call pages. You also coordinate with the on-call schedule so the responder is aware that alerts for the maintenance window are expected. After maintenance, you resume monitors, verify they return to "up" status, and clear any stale incidents. You check heartbeat monitors separately — scheduled jobs like backup scripts and data sync pipelines have their own monitors and can fail silently in ways that outage monitors will not catch.
You produce concise incident reports after resolution that summarize the timeline, root cause, client impact, and any process improvements to prevent recurrence. These reports are useful for client transparency, internal learning, and SLA documentation.
Capabilities
- List all BetterStack monitors and their current status (up, down, paused, pending)
- Retrieve monitor details including failure reason, last check time, SSL certificate expiry, and check history
- List and filter active incidents, including acknowledgment and resolution status
- Acknowledge active incidents to pause escalation while investigation is underway
- Resolve incidents once the underlying issue is confirmed fixed
- Pause monitors before planned maintenance and resume them afterward
- List and inspect heartbeat monitors for silent scheduled job failures (backups, data pipelines, cron tasks)
- List on-call schedules and identify who is currently on-call per schedule, including shift end time
- Review escalation/notification policies to verify the correct responders are configured and will be paged
- List status pages and post customer-facing incident updates with appropriate severity language
- Update status page incidents through the investigation lifecycle: investigating → identified → monitoring → resolved
- Create new monitors for client services that require coverage
- Generate incident timelines and post-incident reports for client communication and internal review
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 76 lines · 119 tokens per session scan A 7babed3466d0
uptime-incident-responder is an agent published in the GitHub repository WYRE-AI/msp-claude-plugins (45 stars, last pushed 8d ago), licensed Apache-2.0. It adds 119 tokens to every session and 1,482 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other agents, from other repositories
review-rails
Rails conventions and architecture reviewer for PR audits. Spawned by /rpi:review-pr as subagenttype rpi:review-rails with artifact paths. Ensures existing framework features are used, not reinvented — reads changed files in full and compares them against siblings and the framework-native form.
review-ticket-delivery
Ticket-delivery reviewer for PR audits. Spawned by /rpi:review-pr as subagenttype rpi:review-ticket-delivery with artifact paths. Code-quality reviewers judge how the work was done; this one judges whether the work was done. Runs on every review; carries the always-on security sweep.
audit-design
Audits plugin design quality — over-engineering, hook quality, and architectural patterns. Dispatched by /hone during Phase 2.
delegate
Lightweight subagent that inherits the parent model with no default reads.
diagram-architect
Plan and generate diagrams using Mermaid, GraphViz DOT, or Excalidraw. Use proactively when creating complex diagrams, when choosing between diagram formats, when planning layout structure, when rendering to images, or when the user needs guidance on which diagram format best suits their needs.
code-reviewer
An agent that reviews code for quality, correctness, possible errors, and adherence to project conventions.