uptime-incident-responder

uptime-incident-responder is an agent for Claude Code from WYRE-AI/msp-claude-plugins. It costs 119 tokens per session (1,482 once invoked), scanned A, original, Apache-2.0.

An incident-response agent for Better Stack, an uptime-monitoring service that alerts teams when websites or services fail.

In plain words
What is it for?
It is for responding to outages, checking failure details and history, coordinating on-call work, updating status information, and preparing incident reports.
Why use it?
It helps an operations team investigate monitor failures, involve the right on-call person, manage the incident, and record what happened.

Agent for Claude Code

Written for Claude Code: shipped in a Claude Code plugin. Also seen: model in frontmatter.

Part of the betterstack plugin — 5 skills, 4 commands, 2 agents shipped together

Good fit It is for responding to outages, checking failure details and history, coordinating on-call work, updating status information, and preparing incident reports.

Compare 6 agents from other repositories ↓
Install with agentmods
npx agentmods add agents/wyre-ai/msp-claude-plugins/uptime-incident-responder
Install

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.

Clone the repo
git clone --depth 1 https://github.com/WYRE-AI/msp-claude-plugins

Made for: Claude Code.

Or install betterstack, the plugin that ships this one along with the rest of its 5 skills, 4 commands, 2 agents.

Wrote 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.

agentmods badge for uptime-incident-responder

README.md
[![agentmods](https://agentmods.dev/badge/agents/wyre-ai/msp-claude-plugins/uptime-incident-responder/github.svg)](https://agentmods.dev/agents/wyre-ai/msp-claude-plugins/uptime-incident-responder)
Your own site
<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.

agentmods 80×15 button for uptime-incident-responder

Your own site · 80×15
<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>
Per session 119 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,482 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce 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

Measured 7d ago against content hash 7babed3466d0, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-11, from the pricing page.

Security

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.

msp-claude-plugins/betterstack/betterstack/agents/uptime-incident-responder.md · 76 lines

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

Read the full file on GitHub · 76 lines

Changes

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.

  1. 7d ago First seen · 76 lines · 119 tokens per session scan A 7babed3466d0

Subscribe to this mod's changes

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.

Related

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.

hoblin/claude-ruby-marketplace · 64 tokens

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.

hoblin/claude-ruby-marketplace · 68 tokens

audit-design

Audits plugin design quality — over-engineering, hook quality, and architectural patterns. Dispatched by /hone during Phase 2.

acostanzo/quickstop · 30 tokens

delegate

Lightweight subagent that inherits the parent model with no default reads.

ethanolivertroy/my-agent-stuff · 15 tokens

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.

johnlarkin1/claude-code-extensions · 59 tokens

code-reviewer

An agent that reviews code for quality, correctness, possible errors, and adherence to project conventions.

DennisLiuCk/claude-plugin-marketplace · 111 tokens