Introduction to Signals

With Signals, you can manage the entire incident management lifecycle in a single platform. Signals offers a complete alerting solution with on-call schedules, escalation policies, and multi-platform notifications to help your team better respond to incidents.

It starts with an Event

All alerts in FireHydrant begin with an incoming event. An Event is created when your monitoring tools (called Event Sources) send a webhook to our platform. The payload from these events are then evaluated against Alert Rules that any of your teams can create. When an event payload matches a rule, an Alert is created and sent to an on-call engineer through an escalation policy.

This provides strategic flexibility to your teams to only subscribe to and be notified by important Events without being fatigued by too much noise.

The other way you can alert users is bypassing Alert Rules entirely and directly notifying against targets. FireHydrant allows bypassing Rules with Targeted Webhooks, which are routed directly to specific targets and will always generate Alerts without the need to define any Rules.

You can learn more about bypassing Rules in Alert Rules.

Responding to Alerts

Users can set their preferences for where and how they receive alerts. They can choose to receive alerts via Slack message, WhatsApp message, SMS, Voice Call, Email, or mobile push notification. This makes it easy for each team member to create a system that works for them when responding to alerts.

No matter where they receive an alert, responders can quickly take action on the alert. They can:

• Acknowledge the alert to stop any additional alerts being sent to the next step of the escalation policy.
• Escalate the alert to send it to the next step of the escalation policy. This is helpful when a responder needs to pass off an alert based on time constraints or context.
• Open an Incident from the alert to kick off your team’s incident management workflow. FireHydrant will pull in key data from the alert to help the team make progress on resolving the incident.
• Dismiss the alert when they’ve determined it’s not an incident or should just be ignored. Alert will be automatically dismissed when a second Event arrives with a “Close” message.
• Resolve the alert or formally mark it as being "handled." An alert can be resolved at any point in the lifecycle unless dismissed or expired. When an alert is connected to an incident, the alert will be automatically resolved when the incident is resolved.
• No action. If no action is taken within the time specified in the Escalation Policy, it will automatically escalate to the next target or hand off to another team if specified.

If an alert fully exhausts the chain of targets in escalation policies and handoffs, it will enter an "expired" state. The Expired state is still open but no longer actively notifying or escalating, and it can remain in this state indefinitely. From here, users can choose to ACK, Resolve, Dismiss, or open an incident from the alert just as they can with an Open alert.

Alerts and Incident Management

A crucial part of responding to incidents is gathering context about what’s disrupting your services and applications. Alerts often contain substantial information, such as links and charts from your monitoring services. Having your alerting tool embedded in your incident management process means that your team can more quickly connect the dots between the data linked to your alerts and the root causes of your incidents.

Once a responder decides to create an incident from an alert, they transition from Signals over to the Incident Management portion of the platform. To read more about promoting alerts into incidents, see Promoting Alerts into Incidents.

Next Steps

• Learn about FireHydrant's On-Call Schedules
• Read more about Escalation Policies