Webhook adapters
Nagios & Icinga
Send Nagios or Icinga notifications to WarnFire with a notification command — problems open incidents, recoveries close them.
If you monitor with Nagios or Icinga, this page connects it to WarnFire so a service or host problem opens an incident and pages your on-call responder, a recovery closes it, and a source acknowledgement is recorded on the incident timeline.
Alerts, not logs. WarnFire consumes Nagios/Icinga notifications — a host or service changing state. It does not read your check output history or performance data. Configure the checks that matter, and WarnFire pages on their notifications.
Unlike newer tools, Nagios and Icinga don’t send webhooks on their own — they run a notification command when a check changes state. You add a command that posts a small message to WarnFire with curl, filling in the details from the notification.
Both products use the same WarnFire message format. They have separate addresses only so each keeps its incidents cleanly separate:
- Nagios:
https://api.warnfire.com/v1/integrations/webhooks/nagios - Icinga:
https://api.warnfire.com/v1/integrations/webhooks/icinga
Before you begin
- A WarnFire service and integration key for these checks. If you do not have one, create the service and its first key .
- Permission to add a command and a contact in your Nagios or Icinga configuration.
The message WarnFire expects
Your notification command sends this JSON. The key travels in the Authorization header — never in the URL.
{
"notification_type": "PROBLEM",
"host": "web-01",
"service": "HTTP",
"state": "CRITICAL",
"output": "HTTP CRITICAL: HTTP/1.1 500",
"time": "1700000000",
"url": "https://nagios.example.com/cgi-bin/status.cgi?host=web-01"
}
- notification_type — send only
PROBLEM,RECOVERY, andACKNOWLEDGEMENT. WarnFire opens or closes the incident for the first two. A source acknowledgement is recorded on the timeline but does not stop paging. - service — leave it out for a host notification; include it for a service notification.
- state — the service state (
OK/WARNING/CRITICAL/UNKNOWN) or host state (UP/DOWN/UNREACHABLE). It sets severity:CRITICAL/DOWN→ critical,WARNING/UNKNOWN→ warning,UNREACHABLE→ error. - time, url — optional.
timeaccepts a Unix timestamp;urlbecomes a jump-back link. - For a source acknowledgement, you can also send author and comment.
Install the safe sender
Install jq, then place this wrapper at
/usr/local/bin/warnfire-notification. It constructs JSON with jq --arg, so
quotes, backslashes, newlines, and shell metacharacters in check output remain
data instead of corrupting the request.
#!/bin/sh
set -eu
adapter=${WARNFIRE_ADAPTER:?WARNFIRE_ADAPTER is required}
case "$adapter" in
nagios|icinga) ;;
*) echo "unsupported WarnFire adapter" >&2; exit 2 ;;
esac
notification_type=${WARNFIRE_NOTIFICATION_TYPE:-${NAGIOS_NOTIFICATIONTYPE:-}}
host=${WARNFIRE_HOST:-${NAGIOS_HOSTNAME:-}}
service=${WARNFIRE_SERVICE:-${NAGIOS_SERVICEDESC:-}}
if [ -n "$service" ]; then
state=${WARNFIRE_STATE:-${NAGIOS_SERVICESTATE:-}}
output=${WARNFIRE_OUTPUT:-${NAGIOS_SERVICEOUTPUT:-}}
else
state=${WARNFIRE_STATE:-${NAGIOS_HOSTSTATE:-}}
output=${WARNFIRE_OUTPUT:-${NAGIOS_HOSTOUTPUT:-}}
fi
event_time=${WARNFIRE_TIME:-${NAGIOS_TIMET:-}}
author=${WARNFIRE_AUTHOR:-${NAGIOS_NOTIFICATIONAUTHORNAME:-}}
comment=${WARNFIRE_COMMENT:-${NAGIOS_NOTIFICATIONCOMMENT:-}}
key_file=${WARNFIRE_KEY_FILE:-/etc/warnfire/integration-key}
integration_key=
IFS= read -r integration_key < "$key_file" || [ -n "$integration_key" ]
payload=$(jq -n \
--arg notification_type "$notification_type" \
--arg host "$host" \
--arg service "$service" \
--arg state "$state" \
--arg output "$output" \
--arg time "$event_time" \
--arg author "$author" \
--arg comment "$comment" \
'{notification_type: $notification_type, host: $host, state: $state, output: $output}
+ if $service == "" then {} else {service: $service} end
+ if $time == "" then {} else {time: $time} end
+ if $author == "" then {} else {author: $author} end
+ if $comment == "" then {} else {comment: $comment} end')
curl --fail-with-body --silent --show-error \
--request POST "https://api.warnfire.com/v1/integrations/webhooks/$adapter" \
--header "Authorization: Bearer $integration_key" \
--header "Content-Type: application/json" \
--data-binary "$payload"
Make the wrapper executable and store only the integration key in a restricted file:
chmod 750 /usr/local/bin/warnfire-notification
install -d -m 700 /etc/warnfire
printf '%s\n' 'wf_live_your_integration_key_here' > /etc/warnfire/integration-key
chmod 600 /etc/warnfire/integration-key
Nagios Core
Enable Nagios environment macros in nagios.cfg so the wrapper receives values
without interpolating them into a shell command:
enable_environment_macros=1
Then define a static notification command:
define command {
command_name notify-service-warnfire
command_line WARNFIRE_ADAPTER=nagios /usr/local/bin/warnfire-notification
}
The wrapper automatically uses the service state and output for service
notifications, or the host state and output when NAGIOS_SERVICEDESC is empty.
Add a contact that uses the command and assign it to the hosts and services that
should page.
Icinga 2
Create a NotificationCommand that passes Icinga runtime macros as environment
values. Icinga sets these without shell evaluation, and the wrapper performs the
JSON encoding and sends Content-Type: application/json:
object NotificationCommand "warnfire-notification" {
command = [ "/usr/local/bin/warnfire-notification" ]
env = {
"WARNFIRE_ADAPTER" = "icinga"
"WARNFIRE_NOTIFICATION_TYPE" = "$notification.type$"
"WARNFIRE_HOST" = "$host.name$"
"WARNFIRE_SERVICE" = "$service.name$"
"WARNFIRE_STATE" = "$service.state$"
"WARNFIRE_OUTPUT" = "$service.output$"
"WARNFIRE_TIME" = "$icinga.timet$"
"WARNFIRE_AUTHOR" = "$notification.author$"
"WARNFIRE_COMMENT" = "$notification.comment$"
}
}
Add a Notification that applies this command to services that should page. For
host notifications, define a second command that sets WARNFIRE_SERVICE to an
empty string and uses $host.state$ and $host.output$ for state and output.
Include Problem, Recovery, and Acknowledgement in the notification’s
types filter so all three lifecycle messages reach WarnFire.
How your notifications become incidents
WarnFire turns each host/service into one incident, using the host and service names to keep its notifications together:
- A PROBLEM opens the incident and paging starts.
- A RECOVERY for the same host/service closes it.
- An ACKNOWLEDGEMENT records the monitoring system’s acknowledgement, author, and comment on the incident timeline. It does not stop escalation. Only a human responder acknowledgement inside WarnFire stops paging; a recovery resolves the incident and cancels escalation.
- A repeat of the same notification is recognized and ignored, so it can’t double-page anyone.
What shows up on the incident
| On the incident | Comes from |
|---|---|
| Title | <service> on <host> is <state> (or just the host for host checks) |
| Severity | The state (see above) |
| Description | The check output, plus the acknowledgement author and comment |
| Source · Component | The host and the service |
| Labels · Details | The notification_type, state, monitor name, check type, and any acknowledgement author and comment |
| Link | View in Nagios / View in Icinga, if you send a url |
Verify it worked
- Follow Test before you connect , choose nagios or icinga, and confirm the preview maps the expected action, title, severity, correlation key, and metadata. Preview does not select or verify a service.
- Choose the intended service for Send test, send the confirmed test, and verify that one test incident opens for that service and pages its on-call responder.
- Put a disposable check into a problem state. Send a source ACKNOWLEDGEMENT and confirm its author and comment appear on the incident timeline while the incident remains triggered and paging remains active.
- Have a human responder acknowledge the incident in WarnFire and confirm that escalation stops.
- Recover the check and confirm that the same WarnFire incident closes.
These tests follow the real incident and escalation path. They can page responders; selected SMS and voice deliveries consume allowance or prepaid credits and can invoke configured auto-recharge. Notify the responder before testing.
If the notification gets an error back
| Error | What it means |
|---|---|
| 401 | The integration key is missing, wrong, expired, or revoked. Check the Authorization header in the command. |
| 400 | The message wasn’t valid — most commonly a notification_type other than PROBLEM/RECOVERY/ACKNOWLEDGEMENT, or a missing host. |
| 429 | The trigger-rate limit or maximum active-incident limit was reached. Check Limits and protections , resolve stale incidents, and then retry. |
Next steps
Use Preview a mapping again before changing the notification command in production.