VictoriaMetrics is a high-performance, cost-efficient time series database widely adopted as a long-term storage backend and drop-in replacement for Prometheus at scale. While VMAlert delivers precise alerting rule execution, those alerts still depend on passive channels for delivery. A webhook that only sends a Slack message at 2 AM is still passive — no matter how accurately the rule fired.
ITOC360 connects to VictoriaMetrics via VMAlert's Alertmanager-compatible webhook endpoint. When an alerting rule fires, ITOC360 identifies the on-call engineer and reaches them via their preferred channel. If there is no acknowledgment, escalation begins automatically. Your existing MetricsQL rules and VMAlert configurations stay completely untouched.
80% of outages are avoidable. VictoriaMetrics identifies the metric breach; ITOC360 ensures a human response matches that precision at any scale.
VMAlert rules reach your on-call team via Voice Call, SMS, or Email instantly. No more unanswered SLO burn alerts or high-cardinality anomalies at 2 AM.
ITOC360 works as an Alertmanager-compatible webhook receiver. If you already use ITOC360 with Prometheus, the same configuration pattern applies — just point VMAlert's notifier URL to your ITOC360 endpoint.
Keep your existing MetricsQL alerting rules, recording rules, and VMAlert configuration files exactly as they are. ITOC360 runs as a parallel escalation receiver.
ITOC360 generates a complete timeline: exactly when VMAlert fired, who was paged, and acknowledgment time. Essential for capacity planning reviews and postmortems.
VictoriaMetrics is the monitoring backend choice for teams that outgrow Prometheus storage limitations — handling billions of data points with exceptional query performance and a fraction of the resource cost. Teams running VictoriaMetrics at scale often have the most business-critical metrics flowing through it: SLO tracking, multi-tenant infrastructure health, long-term trend data.
But scale in your monitoring backend does not automatically mean scale in your incident response. A VMAlert notification that fires at 3 AM and lands only in a Slack channel will sit unread while the underlying issue compounds. ITOC360 closes that gap. The moment VMAlert fires a rule, we find the on-call engineer from your live schedule and reach them directly by phone or SMS. No acknowledgment means automatic escalation through your defined chain — ensuring your high-performance monitoring backend drives high-performance incident response.
VictoriaMetrics identifies the metric breach, but passive notification 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 VictoriaMetrics with ITOC360.
Through VMAlert's -notifier.url flag or notifiers configuration. Point it to your ITOC360 Alertmanager-compatible webhook endpoint. The setup is identical to the Prometheus integration if you already have it configured.
No. ITOC360 accepts VMAlert's native webhook payload directly. You do not need to run Alertmanager as a middleman unless you already use it for other routing logic.
Yes. Both send Alertmanager-compatible webhook payloads, so a single ITOC360 service endpoint can receive alerts from both sources. Use labels to differentiate sources for routing if needed.
Yes. VMAlert supports label-based routing via notifier configuration. You can send only production-critical alerts to ITOC360 while routing lower-severity alerts to other channels.
Yes. ITOC360 works with both VictoriaMetrics single-node deployments and the full cluster architecture (vminsert, vmselect, vmstorage + vmalert). The integration is at the VMAlert notification layer, which is consistent across both deployment modes.
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.
