rootlyhq/rootly

Assess a Rootly alert or alert group and recommend opening an incident, attaching it to one, waiting with a clear recheck condition, or dismissing verified noise. Use for pages and alerts before the incident investigation begins.

Assess a proposed deploy using its diff, review and test evidence, rollout safeguards, and Rootly incident context. Recommend GO, CAUTION, or NO-GO with reasons; use before deploying a branch, PR, release, or configuration change, without executing it.

Draft responder, executive, customer, or incident commander handoff updates from Rootly incident evidence. Use for stakeholder briefs and status-update drafts; distinguish confirmed impact from internal hypotheses and never publish messages.

Investigate outages and active incidents with Rootly context. Use when asked to investigate a failure, assess impact, compare simultaneous incidents, choose mitigation or responders, or decide whether to wait for a vendor, including when the user supplies the evidence. Use alert-triage for unassigned alerts and incident-communications for audience-specific updates.

Look up Rootly on-call coverage and personal shifts, prepare shift handoffs, and recommend coverage changes using schedule, workload, expertise, and explicit availability. Use for shifts, handoffs, swaps, or coverage planning without modifying schedules.

Prepare a Rootly post-incident review with sourced metadata, timeline, impact evidence, facilitation questions, and action proposals. Use for retrospectives and incident action-item reviews; preserve human ownership of conclusions, disputed causes, and roadmap commitments.

Assess whether a service is down, healthy, or deteriorating from errors, latency, traffic, and their baselines. Use for zero-traffic questions, recurring spikes, health checks and trends, service or owner lookup, and recent deploy context, including when evidence is already supplied. Include available Rootly incident, ownership, and on-call records; incident counts alone cannot establish health.