Checkmk gives your operations team precise visibility into hosts, services, and network devices. But when a CRITICAL alert fires at 3 AM, a notification script that silently logs to a file or sends a single email does not guarantee a human response. Engineers miss alerts, SLAs slip, and downtime extends.
ITOC360 connects directly to Checkmk as a native notification script. When your defined thresholds trigger, ITOC360 identifies the current on-call engineer from your schedule and reaches them via their preferred channel. If there is no acknowledgment, escalation begins automatically.
80% of outages are avoidable. Checkmk identifies the issue; ITOC360 ensures a human response matches that detection speed.
Voice call, SMS, or email delivered the moment Checkmk fires a PROBLEM notification.
Functions as a standard Checkmk notification script. No changes to your existing hosts, services, or threshold configuration.
Checkmk WARNING maps to Medium, CRITICAL maps to Critical. Escalation policies respond accordingly.
When Checkmk sends a RECOVERY notification, ITOC360 closes the active alert automatically.
Checkmk is exceptional at detecting infrastructure problems. The gap appears after detection: the alert is dispatched via the configured notification method and the process stops. If the engineer is asleep, offline, or has notifications silenced, the PROBLEM continues until someone manually checks the dashboard.
ITOC360 closes this gap. When Checkmk triggers the notification script, ITOC360 looks up who is on-call at that exact moment and actively reaches them. If the first responder does not acknowledge within your configured timeout, the system escalates to the next level automatically. Your existing Checkmk configuration remains completely unchanged.
Checkmk identifies the issue, but passive channels cannot guarantee a human response. ITOC360 bridges that gap, notifying the right expert via their preferred channel and escalating until someone responds.
Common questions about integrating Checkmk with ITOC360.
Via a custom notification script (itoc360.sh) placed in your Checkmk notification scripts directory. The script sends a POST request to the ITOC360 API with the alert payload. You add it as a notification rule in Checkmk Setup and provide your ITOC360 token as a parameter.
No. You add ITOC360 as an additional notification rule. Existing rules for email or other methods continue operating in parallel.
Yes. Create separate notification rules in Checkmk scoped to specific host groups or services, each pointing to a different escalation policy in ITOC360.
OK maps to LOW, WARNING to MEDIUM, and CRITICAL to CRITICAL. UNKNOWN defaults to MEDIUM. These priorities drive which escalation policy levels are triggered.
Yes. ITOC360 records the full incident timeline: when Checkmk fired the alert, when the first notification was sent, and when an engineer acknowledged the incident.
Alert storms, manual processes, missed incidents, and no clear ownership cause long MTTR and burned-out engineers. Your on-call engineers should only wake up when it truly matters.
