> For the complete documentation index, see [llms.txt](https://docs.itoc360.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.itoc360.com/integrations/inbound-integrations/infrastructure-monitoring/prtg-network-monitor-integration.md). # PRTG Network Monitor Integration [PRTG Network Monitor](https://www.paessler.com/prtg) 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 custom `Authorization` header, 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= ▼ ITOC360 Webhook Endpoint │ │ URL-encoded body parsed → schema validated │ Fingerprint: md5(device::sensor::sensorid) ▼ Alert opened or resolved → On-call team notified ``` ### Provider 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 ```json { "priority": { "field": "$.status", "options": [ { "value": "Down", "label": "Down" }, { "value": "Warning", "label": "Warning" }, { "value": "Unusual", "label": "Unusual" }, { "value": "Up", "label": "Up" }, { "value": "Paused", "label": "Paused" }, { "value": "Unknown", "label": "Unknown" } ], "mapping": { "Down": "CRITICAL", "Warning": "MEDIUM", "Unusual": "LOW", "Up": "LOW", "Paused": "LOW", "Unknown": "LOW" } } } ``` **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 | PRTG Status | Platform Priority | What it means | | ----------- | ----------------- | ------------------------------------------------------ | | 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 | PRTG Status | Event Type | Result | | ------------------------------------------- | ---------- | ----------------------------------- | | 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 1. Log in to the platform and go to **Sources → Add Source**. 2. Choose **PRTG Network Monitor** and give the source a name. 3. Save it. You'll get a webhook URL that looks like this: ``` https://api.itoc360.app/functions/v1/events?token= ``` Copy this — you'll need it in the next step. #### Step 2: Create a Notification Template in PRTG 1. Head to **Setup → Account Settings → Notification Templates**.
2. Click **Add Notification Template** and give it a name like `OnCall Platform Webhook`. 3. In **Basic Settings**, a couple of things to set: | Setting | Value | | -------------------------------------------- | ---------------------------------------------- | | Monitoring 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 `%sensorid` placeholder can arrive empty. Since `sensorid`is a required field, ITOC360 rejects the payload with `400 Invalid payload` and the alert is never opened.
4. Scroll down, find **Execute HTTP Action**, and enable it. 5. Fill it in like this:
FieldValue
URLhttps://api.itoc360.app/functions/v1/events
HTTP MethodPOST
HTTP VersionHTTP 1.1
SNI HandlingDo not send SNI (default)
6. In the **Payload** field, paste this: ``` sensorid=%sensorid&device=%device&sensor=%sensor&status=%status&message=%message&since=%since&lastup=%lastup&lastdown=%lastdown&downtime=%downtime&group=%group&probe=%probe&host=%host&linkdevice=%linkdevice&linksensor=%linksensor&deviceid=%deviceid ```
7. 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. 1. In the device tree, open the **Root** group (or whichever group you want to cover). 2. Go to the **Notification Triggers** tab. 3. Add three **State Triggers**, configured like this: | Trigger | Row | Template | | ------- | ------------------------------------------------------- | --------------- | | 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 ``` sensorid=1004 device=Probe Device sensor=Disk Free (WMI Free Disk Space (Multi Disk)) status=Down message=73 % (Free Space C:) is below the error limit of 90 % in Free Space C: since=13.08.2026 17:19:31 lastup=13.08.2026 17:18:31 lastdown=13.08.2026 17:19:31 downtime=0,0004% [61 s] group=Local Probe probe=Local Probe host=127.0.0.1 deviceid=40 linkdevice=https://prtg.example.com/device.htm?id=40 linksensor=https://prtg.example.com/sensor.htm?id=1004 ``` Opens a CRITICAL alert. #### Resolve — Sensor Back Up ``` sensorid=1004 device=Probe Device sensor=Disk Free (WMI Free Disk Space (Multi Disk)) status=Up message=OK since=13.08.2026 17:23:31 lastup=13.08.2026 17:23:31 lastdown=13.08.2026 17:22:31 downtime=0,0016% [4 m 1 s] group=Local Probe probe=Local Probe host=127.0.0.1 deviceid=40 linkdevice=https://prtg.example.com/device.htm?id=40 linksensor=https://prtg.example.com/sensor.htm?id=1004 ``` 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 | Symptom | Cause | What to do | | -------------------------------------------------- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | 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 Pause**to *Discard notifications during paused status*. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.itoc360.com/integrations/inbound-integrations/infrastructure-monitoring/prtg-network-monitor-integration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.