WarnFireDocs

Webhook adapters

Nagios & Icinga

Send Nagios or Icinga notifications to WarnFire with a notification command — problems open incidents, recoveries close them.

Version 1.0 Status Needs verification For Integration operators webhooksnagiosicingamonitoring

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, and ACKNOWLEDGEMENT. 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. time accepts a Unix timestamp; url becomes 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 incidentComes from
Title<service> on <host> is <state> (or just the host for host checks)
SeverityThe state (see above)
DescriptionThe check output, plus the acknowledgement author and comment
Source · ComponentThe host and the service
Labels · DetailsThe notification_type, state, monitor name, check type, and any acknowledgement author and comment
LinkView in Nagios / View in Icinga, if you send a url

Verify it worked

  1. 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.
  2. 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.
  3. 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.
  4. Have a human responder acknowledge the incident in WarnFire and confirm that escalation stops.
  5. 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

ErrorWhat it means
401The integration key is missing, wrong, expired, or revoked. Check the Authorization header in the command.
400The message wasn’t valid — most commonly a notification_type other than PROBLEM/RECOVERY/ACKNOWLEDGEMENT, or a missing host.
429The 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.