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.
