ITOC360 for Graylog

Maintained by the ITOC360 team.

Route Graylog event notifications into ITOC360 for on-call alerting, escalation and incident management.

ITOC360 is an incident response platform: it receives alerts from your monitoring stack, deduplicates them, applies priority and escalation policies, and pages the right on-call engineer through push, SMS, voice and chat channels.

This integration lets Graylog act as an alert source for ITOC360 using Graylog's built-in HTTP Notification — no plugin, no agent and no code to deploy on the Graylog side.

Why use it

• On-call scheduling for Graylog alerts. Graylog notifications go to a rotation with escalation rules instead of a shared inbox or a chat channel nobody owns at 03:00.
• Deduplication. Repeated triggers of the same event definition collapse into a single alert instead of flooding your team.
• Priority mapping. Graylog event priority is translated to ITOC360 priority, so a High-priority definition escalates faster than an informational one.
• Incident lifecycle. Alerts can be acknowledged, escalated, grouped into incidents, silenced during maintenance windows, and reported on.

Requirements

• Graylog 4.0 or later (any edition — Open, Operations or Security), with permission to create Notifications and Event Definitions.
• An ITOC360 account. A source token is generated in the ITOC360 UI; no API key, OAuth app or marketplace purchase is required.
• Outbound HTTPS (443) from the Graylog server to api.itoc360.app.

Installation

1. Create the Graylog source in ITOC360

1. In ITOC360, go to Management → Sources → New Source.

2. Select Graylog as the provider and give the source a name (for example graylog-prod).

3. Save, then copy the generated webhook URL. It looks like this:

   https://api.itoc360.app/functions/v1/events?token=<YOUR_SOURCE_TOKEN>
   

Treat the token as a secret — anyone holding it can create alerts in your tenant. Rotate it from the same screen if it leaks.

2. Create the notification in Graylog

1. Go to Alerts → Notifications → Create notification.
2. Set Notification type to HTTP Notification.
3. Title: ITOC360
4. URL: paste the webhook URL from step 1.
5. Save.

Graylog posts its standard event notification body to that URL. No custom payload template, header or authentication configuration is needed.

3. Attach the notification to your event definitions

1. Go to Alerts → Event Definitions and edit (or create) a definition.
2. In the Notifications step, add the ITOC360 notification.
3. Set the definition's Priority — this drives the priority of the resulting ITOC360 alert.
4. Save.

Repeat for every event definition that should page someone. One notification can be reused across all of them.

Verifying the integration

Trigger any event definition that has the notification attached, then open Monitoring → Alerts in ITOC360. A new alert should appear within a few seconds carrying the event definition title, the log message and the mapped priority. The raw Graylog notification body is stored on the alert under Metadata, which is the fastest way to debug a mapping problem.

To test without waiting for a real event, send the notification body manually:

curl -X POST 'https://api.itoc360.app/functions/v1/events?token=<YOUR_SOURCE_TOKEN>' \
  -H 'Content-Type: application/json' \
  --data '{
    "event": {
      "id": "01TEST00000000000000000000",
      "key": "",
      "alert": true,
      "source": "graylog-test",
      "message": "ITOC360 connectivity test",
      "priority": 2,
      "timestamp": "2026-01-01T00:00:00.000Z"
    },
    "backlog": [],
    "event_definition_id": "connectivity-test",
    "event_definition_title": "ITOC360 connectivity test",
    "event_definition_description": ""
  }'

A 2xx response with an event id means the source token and payload were accepted.

How events are mapped

Graylog field	ITOC360 field
event_definition_title	Alert title
event.message	Alert message
event.source	Source host
event.priority	Alert priority
event.timestamp	Event time
event_definition_id + event.key	Deduplication fingerprint
backlog	Attached log context

Priority

Graylog priority	ITOC360 priority
1 (Low)	LOW
2 (Normal)	MEDIUM
3 (High)	HIGH

If a definition sends no usable priority, the alert defaults to MEDIUM. The mapping can be overridden per source in ITOC360.

Deduplication

The fingerprint is derived from the event definition id combined with the event key. In practice:

• Event definitions without grouping fields send an empty event.key, so every trigger of that definition deduplicates into one open alert. Repeated triggers are appended to the alert's event timeline rather than paging again.
• Event definitions with grouping fields configured send a populated event.key, so each distinct group (per host, per service, and so on) gets its own alert.

If you want one alert per affected host instead of one alert per definition, configure grouping fields on the Graylog event definition.

Resolution

Graylog does not send a recovery or resolution notification. Its event system emits a notification when a condition matches and nothing when the condition stops matching. This is a Graylog behaviour, not an integration limitation, and it means alerts from Graylog do not close by themselves.

Close them in one of these ways:

• Resolve the alert or its incident manually in ITOC360 once the underlying issue is fixed.
• Configure an auto-close policy on the ITOC360 source so alerts that stop repeating are closed after a defined interval.

If you need true state tracking, pair the alerting definition with a second definition that matches the recovered condition and route it to a separate workflow.

Troubleshooting

Symptom	Cause and fix
Source not found	The token in the URL does not match an active ITOC360 source. Re-copy it; check for a truncated paste or a stale token after rotation.
Invalid payload	The request body does not match the expected Graylog notification shape. This normally means a custom body template was configured on the notification — remove it and let Graylog send its default body.
Nothing arrives in ITOC360	Check System → Overview → Notifications in Graylog for failed notification deliveries, then confirm the Graylog server can reach api.itoc360.app on 443 (proxies and egress firewalls are the usual culprits).
Alerts arrive but nobody is paged	The ITOC360 source is not attached to an escalation policy, or the alert priority falls below the policy threshold.
Repeated triggers create one alert instead of many	Expected behaviour. Configure grouping fields on the event definition to split them — see Deduplication.
Alerts never close	Expected behaviour. Graylog sends no recovery event — see Resolution.

Documentation and support

• Integration guide: https://docs.itoc360.com/integrations/inbound-integrations/log-management/graylog-integration
• Product: https://itoc360.com
• Issues with this listing: open an issue in this repository.

License

MIT — see LICENSE.