FireHydrant

FireHydrant

Incident management platform for declaring, triaging, automating, and reviewing incidents across services and teams. Covers the full incident lifecycle from alert to post-mortem.

Entity Hierarchy

The data model has three layers: catalog (what you own), incident (what's happening), and retrospective (what happened).

Catalog (steady-state configuration)

• Services — things that can break (microservices, infrastructure components). Each has an owner team and environment links. Search by name with query. Open a service by id for full details.
• Teams — groups of people who respond. Linked to services, on-call schedules, and incident roles.
• Users — individual responders.
• Environments — deployment targets (production, staging). Incidents are scoped to environments.
• Infrastructures — broader infra components (AWS region, data center).
• Functionalities — user-facing capabilities a service provides ("checkout flow", "search").

Incident Configuration

• Severities — ordered severity levels (SEV1–SEV5 or custom). Drives SLA timers and escalation.
• Priorities — urgency ordering, separate from severity.
• Incident Types — classification categories (security, performance, outage).
• Incident Roles — responsibilities during response (Incident Commander, Communications Lead).
• Incident Tags — freeform labels for filtering and reporting.
• Phases — lifecycle stages an incident moves through (detected → acknowledged → mitigated → resolved).
• Severity Matrix — conditions × impacts grid that auto-assigns severity. Query conditions and impacts separately.

Automation

• Runbooks — step-by-step automation playbooks attached to incidents. Each runbook has actions (individual steps) and executions (historical runs). Audits track who changed runbook definitions.
• Checklist Templates — manual task checklists for common incident procedures.
• Task Lists — incident-scoped lists of assigned work items.

Signals & Alerting

• Alerts — inbound alert events from monitoring tools (PagerDuty, Datadog, etc.).
• Signals On-Call — who is currently on call and receiving alerts.

Incident Operations

• Incidents — the core entity. Each has severity, priority, type, affected services, environments, and assigned teams/roles. Filter by status (open/in_progress/resolved/closed), severity (SEV1-SEV5), or search by query. Open an incident by id for the full timeline.
• Changes — deployment and configuration change records linked to the service catalog. Change Events are the individual events within a change.
• Scheduled Maintenances — planned downtime windows.

Retrospective

• Post-Mortem Reports — completed post-incident reviews linked to specific incidents.
• Post-Mortem Questions — configurable question templates used across post-mortems.
• Reports — aggregated MTTA (mean time to acknowledge) and MTTR (mean time to resolve) metrics.

Integrations & Ticketing

• Integrations — connected third-party tools (Slack, Jira, PagerDuty).
• Webhooks — outbound event hooks.
• Tickets — external tracking tickets linked to incidents. Ticket Tags and Ticketing Priorities configure the ticketing system. Ticketing Projects organize tickets.
• Custom Field Definitions — schema for custom data on incidents.
• Entitlements — account-level feature flags and plan limits.
• NUNC Connections — status page connections for public incident communication.

Workflows

• Triage an alert: list alerts → find the relevant alert → list incidents to see if one already exists → check services and on-call schedules.
• Assess impact: list services and functionalities to understand what's affected → query severity matrix conditions/impacts to see auto-severity logic → list environments to scope the blast radius.
• Review response capacity: list teams → list users → check signals on-call for current responders → list incident roles for assignment needs.
• Audit automation: list runbooks → drill into runbook executions for recent runs → review runbook audits for definition changes → list checklist templates for manual procedures.
• Post-incident analysis: list post-mortem reports → review post-mortem questions for standard retrospective structure → pull mean-time reports for MTTA/MTTR trends.
• Change correlation: list changes and change events around an incident timeframe to identify causal deployments.

Gotchas

• Rate limit: 50 requests per 10 seconds (300/min); back off when responses indicate throttling.
• Pagination: most lists use page index + page size; responses include pagination metadata.
• Measurement definitions sit under lifecycle measurement resources, not the API root.
• Phases sit under lifecycle resources.
• Mean-time reports return aggregate MTTA/MTTR style metrics—not arbitrary document lists.