# PRTG Network Monitor Integration [PRTG](https://www.paessler.com/prtg-1) is a network monitoring tool by Paessler AG. It keeps tabs on servers, routers, switches, bandwidth — basically anything you'd want to know is still alive in your infrastructure. Getting it connected to the platform is straightforward. PRTG has a built-in notification method called Execute HTTP Action that lets you fire a POST request whenever a sensor changes state. We use this to ship alerts straight to the platform's webhook endpoint, which then handles the rest — validation, deduplication, escalation, the works. One thing worth knowing upfront: PRTG doesn't send JSON. It sends `application/x-www-form-urlencoded` — the same format old HTML forms use. There's also no way to set a custom Authorization header. So instead of a Bearer token in the header, you'll put the token directly in the URL as a query parameter. It's a PRTG limitation, not ours, and the platform handles it fine. ### Integration Flow ``` PRTG Sensor State Change │ │ Notification Trigger fires ▼ Execute HTTP Action │ │ POST application/x-www-form-urlencoded │ URL: /functions/v1/events?token= ▼ Platform 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" } } } ``` #### Status → Priority | PRTG Status | Platform Priority | What it means | | ----------- | ----------------- | ------------------------------------------ | | Down | CRITICAL | Sensor failed or unreachable | | 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 | **Fingerprinting:** The platform uses `md5(device::sensor::sensorid)` to tie alerts to their recovery events. As long as the sensor identifiers stay the same — which they always do in PRTG — the resolve will land on the right alert without any manual work. ### 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:///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: * **Monitoring Status:** Started * **Notification Handling during Scheduled Pause:** Pick *Discard notifications during paused status* — otherwise PRTG will spam the platform whenever a monitor is paused. * **Notification Summarization:** The default (*Send first down and up message immediately, then summarize*) is fine.
4. Scroll down, find **Execute HTTP Action**, and enable it. 5. Fill it in like this: | Field | Value | | ------------ | ---------------------------- | | URL | Your webhook URL from Step 1 | | HTTP Method | POST | | HTTP Version | HTTP 1.1 | 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 won't do anything 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. Set up triggers for the states you care about: | Trigger | Condition | Template | | ------------- | ---------------------- | ----------------------- | | State Trigger | Sensor goes Down | OnCall Platform Webhook | | State Trigger | Sensor goes to Warning | OnCall Platform Webhook | | State Trigger | Sensor returns to Up | OnCall Platform Webhook | > On the Down trigger, turn on *repeat every X minutes*. If the first notification fails because of a network issue, PRTG will keep retrying instead of going silent. #### Step 4: Test It No need to kill a real sensor. PRTG can send a test notification from the template itself. 1. Open your notification template and scroll to the bottom. 2. Click **Send Test Notification**.
> 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. ### Payload Examples #### Alert — Sensor Down ``` sensorid=1001 device=web-server-01 sensor=Ping status=Down message=Timeout (ping) [9 %] - 90% packet loss since=01/05/2026 14:23:10 lastup=01/05/2026 14:22:45 lastdown=01/05/2026 14:23:10 downtime=0 days 0 hours 0 minutes group=Production Servers probe=Local Probe host=192.168.1.100 linkdevice=https://prtg.example.com/device.htm?id=2001 linksensor=https://prtg.example.com/sensor.htm?id=1001 deviceid=2001 ``` #### Resolve — Sensor Back Up ``` sensorid=1001 device=web-server-01 sensor=Ping status=Up message=OK (ping) [100 %] - 0% packet loss since=01/05/2026 14:25:30 lastup=01/05/2026 14:25:30 lastdown=01/05/2026 14:23:10 downtime=0 days 0 hours 2 minutes group=Production Servers probe=Local Probe host=192.168.1.100 linkdevice=https://prtg.example.com/device.htm?id=2001 linksensor=https://prtg.example.com/sensor.htm?id=1001 deviceid=2001 ``` --- # Agent Instructions: 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: ``` GET https://docs.itoc360.com/integrations/inbound-integrations/infrastructure-monitoring/prtg-network-monitor-integration.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.