Declaration

What is an incident declaration? 

An incident declaration is when someone at an organization officially documents a system degradation and kicks off the company's incident response process.

To do this, some organizations declare incidents manually directly in their incident management platform or call up the declaration process from their code line interface via an API. Others use alert routing to automatically open incidents when a third-party monitoring or incident response tool generates an alert. In FireHydrant, you can declare a new incident in our Slack app by typing /firehydrant new.

Best practices for incident declaration

As you think about creating an incident declaration process that anyone can follow — technical or non-technical, consider these best practices:

Only include the fields that really matter

Think strategically about which fields in your incident declaration forms are essential and which are just "nice to have." The more fields you include, the less likely someone will fill out the entire form. And you can always go back and gather information later (or set a reminder to do it for you).

Align your team on priorities

Be sure to educate team members on your organization's priorities. If the business values declaration speed over accuracy, communicating that to your responders during training sessions and documentation will go a long way toward boosting confidence in the declaration process. If your organization places more value on speed, acknowledge that you're comfortable losing the initial period of documented investigation for the sake of mitigation.

Offer a list of pre-written incident types

To make it easier for anyone in the company to declare an incident, consider creating a list of incident types. Providing these pre-written descriptions removes the cognitive load of explaining the incident from scratch. 

Introduce a 'triage' severity

Sometimes, a team member won't know how to assign a severity level when they declare an incident. Add a 'triage' option: a field for roughly describing the incident without kicking off decisive action. Behind the scenes, this 'triage' field doesn't need to have automation attached to it. For example, the FireHydrant team set up our 'triage' severity to open an incident channel — nothing else. This way, false alarms or inaccurate assessments of an incident won't cause the chain reaction of automation that setting an official severity level would. 

Make a plan for what happens next

Decide what should happen right after a team member declares an incident. How will you assemble the right problem solvers into the correct communication space, such as a Slack channel or Zoom room? Is there a set process they can follow to remediate the issue? Who is responsible for seeing the entire process through to the end?