PRTG Network Monitor Integration
PRTG Network Monitor is a network monitoring tool by Paessler AG. It watches servers, routers, switches, bandwidth, and disk usage across your infrastructure.
PRTG connects to ITOC360 through its built-in Execute HTTP Action notification method, which fires a POST request whenever a sensor changes state. ITOC360 handles the rest — validation, deduplication, priority mapping, and escalation.
Note: PRTG does not send JSON. It sends
application/x-www-form-urlencoded, the same format used by classic HTML forms. It also cannot set a customAuthorizationheader, so the source token goes in the URL as a query parameter. This is a PRTG limitation and ITOC360 handles it without any extra configuration.
Integration Flow
PRTG Sensor State Change
│
│ Notification Trigger fires
▼
Execute HTTP Action
│
│ POST application/x-www-form-urlencoded
│ URL: /functions/v1/events?token=<source-token>
▼
ITOC360 Webhook Endpoint
│
│ URL-encoded body parsed → schema validated
│ Fingerprint: md5(device::sensor::sensorid)
▼
Alert opened or resolved → On-call team notifiedProvider Configuration & Mapping
PRTG dumps everything into flat key-value pairs, so priority extraction is simple — we just read the status field directly. No JSONPath needed.
Priority Mapping Config
Fingerprinting: ITOC360 uses md5(device::sensor::sensorid) to tie alerts to their recovery events. Sensor identifiers never change in PRTG, so the resolve always lands on the right alert without any manual work.
Status → Priority
Down
CRITICAL
Sensor failed, unreachable, or breached an error limit
Warning
MEDIUM
Crossed a warning threshold
Unusual
LOW
Behaviour looks off but not confirmed down
Up
LOW
Sensor recovered — triggers a resolve
Paused
LOW
Monitoring paused intentionally
Unknown
LOW
Can't determine state
Event Type Mapping
Down / Warning / Unusual / Paused / Unknown
ALERT
Alert opened or updated
Up / Recovering
RESOLVE
Existing alert closed automatically
Setup Instructions
Step 1: Get Your Webhook URL
Log in to the platform and go to Sources → Add Source.
Choose PRTG Network Monitor and give the source a name.
Save it. You'll get a webhook URL that looks like this:
Copy this — you'll need it in the next step.
Step 2: Create a Notification Template in PRTG
Head to Setup → Account Settings → Notification Templates.
Click Add Notification Template and give it a name like
OnCall Platform Webhook.In Basic Settings, a couple of things to set:
SettingValueMonitoring Status
Started
Schedule
None
Notification Handling during Scheduled Pause
Discard notifications during paused status
Notification Summarization
Always notify immediately, never summarize
Important: Change Notification Summarization from its default. When PRTG summarizes notifications it merges several state changes into one message, and the
%sensoridplaceholder can arrive empty. Sincesensoridis a required field, ITOC360 rejects the payload with400 Invalid payloadand the alert is never opened.
Scroll down, find Execute HTTP Action, and enable it.
Fill it in like this:
FieldValueHTTP Method
POST
HTTP Version
HTTP 1.1
SNI Handling
Do not send SNI (default)
In the Payload field, paste this:
Hit Save.
Step 3: Attach the Template to a Trigger
The notification template does nothing on its own — it needs to be connected to a trigger.
In the device tree, open the Root group (or whichever group you want to cover).
Go to the Notification Triggers tab.
Add three State Triggers, configured like this:
Down
When sensor state is Down for at least 0 seconds
ITOC360 Webhook
Down
Repeat every 5 minutes
ITOC360 Webhook
Warning
When sensor state is Warning for at least 0 seconds
ITOC360 Webhook
Up
When sensor state is Up for at least 0 seconds
ITOC360 Webhook
Watch the row you attach the template to. Each State Trigger has three rows: entering the state, repeating while in the state, and leaving the state. Attach the template to the entering row. If you attach it to "when sensor state is no longer X", the alert is never opened — only the recovery fires. Leave every other row set to no notification.
Enabling repeat every 5 minutes on the Down trigger is safe: repeated notifications carry the same fingerprint, so ITOC360 updates the existing alert instead of opening duplicates. Don't enable repeat on Warning or Up.
Step 4: Set Sensors to Down Immediately
By default PRTG holds a failing sensor in Warning for one scanning interval before marking it Down. The first webhook therefore arrives with status=Warning and opens a MEDIUM alert. Once the alert exists its priority stays as it was created, so a genuine failure never escalates to CRITICAL.
For sensors that matter, open the sensor's Settings → Scanning Interval and set If a Sensor Query Fails to Set sensor to "down" immediately.
Error-limit breaches are not affected — those go straight to Down and arrive as CRITICAL.
Step 5: Test It
You don't need to wait for a real outage.
Option 1 — Simulate Error Status. Open any Up sensor and choose Simulate Error Status from its context menu. Note that with default settings this arrives as status=Warning first (see Step 4). Use Resume to recover it.
Option 2 — Breach an error limit. Open a sensor with a numeric channel (a disk-space sensor works well), set Lower Error Limit above the current value, and save. The sensor drops straight to Down and the webhook arrives with status=Down. Restore the original limit to resolve it.
Option 3 — Send Test Notification. Open your notification template, scroll to the bottom, and click Send Test Notification. This confirms connectivity but does not populate real sensor values.
To verify the result: in PRTG check Logs → System Events → Notifications for the HTTP response code, and in ITOC360 open Alerts to confirm the alert opened with the expected priority.
The screenshot above shows exactly how PRTG's payload looks when it arrives — flat key-value pairs, not JSON. The platform parses this automatically before running validation.
Acknowledging Alerts
Acknowledging a sensor in PRTG does not close the corresponding ITOC360 alert.
PRTG state triggers fire on state changes. Acknowledging marks the sensor inside PRTG but does not change its state, so no webhook is sent and ITOC360 never learns about it. The alert stays open at its original priority until the sensor returns to Up.
Acknowledge alerts in ITOC360 instead, where the acknowledgement feeds into escalation policies.
Payload Examples
Alert — Sensor Down
Opens a CRITICAL alert.
Resolve — Sensor Back Up
Closes the alert opened above. Note that lastdown may arrive empty on the first alert of a sensor's lifetime; this does not affect validation.
Troubleshooting
No alerts arrive at all
The template is attached to the "no longer X" row of the trigger.
Attach it to the for at least 0 seconds row instead. See Step 3.
400 Invalid payload in the PRTG notification log
Notification summarization merged messages and dropped sensorid.
Set Notification Summarization to Always notify immediately, never summarize.
Real failures arrive as MEDIUM instead of CRITICAL
PRTG held the sensor in Warning for one interval before Down.
Set If a Sensor Query Fails to Set sensor to "down" immediately. See Step 4.
Alert stays open after acknowledging in PRTG
Acknowledging does not change sensor state, so no webhook is sent.
Acknowledge the alert in ITOC360. See Acknowledging Alerts.
Recovery never closes the alert
The Up trigger is missing or attached to the wrong row.
Add a State Trigger for Up at 0 seconds.
Paused sensors open alerts
The Paused state maps to ALERT.
Set Notification Handling during Scheduled Pauseto Discard notifications during paused status.
Last updated
Was this helpful?