Monitoring

See every heartbeat. Catch every incident.

Synthetic probes from your regions, anomaly detection that catches drift, and severity-aware routing to every channel your operators already live in.

Request a demo Read the docs

DetectionUptime · Anomaly · Platform
MathEMA + Bollinger
Channels9 actions · 15+ connectors

Capabilities · deep dive

Seven properties that catch every incident before the ticket arrives.

Uptime probes from your regions; anomaly detection with EMA and Bollinger bands; ten platform alert triggers ready on day one; CPU and memory rules per component; severity-aware action chains to Slack, Teams, ServiceNow, email, webhook, and more; four severity grades with full audit; and one operations dashboard for all four lanes — every property a real Apinizer capability, not a roadmap promise.

01 · Uptime monitoring

Probe like a customer. From everywhere they live.

Synthetic checks run from the regions your gateway already does — and validate not just a 200 OK, but the right body, headers, and latency budget the SLA promises.

Three targets — managed proxy, backend API, external endpoint
Schedule · 1 / 5 / 10 / 30 minutes or a cron expression
Assertions · status, body, XPath, JsonPath
Retry on fail with configurable count and delay
Same monitor on every environment — dev, test, production

3 target types
Status · body · XPath · JsonPath
Retry on fail
Multi-environment

Uptime health view — a sixty-cell hourly status grid runs across the top, mostly green with one amber minute mid-hour and two red minutes near the end; six region and environment rows underneath show success ratios for production Istanbul, production Frankfurt, disaster-recovery Ankara, partner Baku, development Amsterdam, and test London, each with a coloured progress bar and a percentage; a status pill in the header reports the rolling thirty-day availability.

02 · Anomaly detection

Catch issues no threshold could.

EMA with Bollinger bands evaluates the trend, not just the value. Two sliders tune sensitivity; one toggle picks fire-per-event or once-per-series.

Any Elasticsearch query as the source
EMA with upper and lower Bollinger bands
Sensitivity · data points + standard deviation multiplier
Execute mode · per event or once per series
Charted detection — metric, EMA, bands, every marker

Threshold
EMA + Bollinger
Per event / series
Trend-aware

An anomaly detection chart shows the metric line crossing an EMA centerline and its upper and lower Bollinger bands; three red markers appear where the metric breaks the band; a sensitivity panel pins data points and standard deviation multiplier sliders, and an execute-mode toggle picks between per-anomaly-event and once-per-anomaly-series.

03 · Platform alerts

Pods, nodes, certificates — every alert your operators want.

Ten triggers ship with the platform — Kubernetes, Elasticsearch, certificates, and logs. Each comes with a threshold, a schedule, a severity, and the same action chain you use everywhere else.

Kubernetes · pod health, node health, node CPU
Elasticsearch · cluster health, CPU, disk
Certificates · SSL and JWK expiry windows
Logs · application log count and traffic log presence
Same severity grades and action chains as everything else

10 triggers
Kubernetes
Elasticsearch
SSL · JWK
Log presence

A grid of nine alert trigger cards organized in three rows — Kubernetes covering pod health, node health, and node CPU; Elasticsearch covering cluster health, CPU, and disk percentage; certificates and logs covering SSL expiry, JWK expiry, and application log count; each card carries a severity pill, a current value, and a last-fired timestamp; a footer card pins the tenth trigger for API traffic logs presence in the database.

04 · System health

CPU and memory. Per component. Sustained.

Manager, Gateway Worker, Cache, and Log — each has its own threshold and duration window. A one-second spike never pages anyone; eighty percent for thirty seconds does.

Per-component thresholds for Manager, Worker, Cache, Log
Duration window — sustained-over-time, not a spike
Same severity grades as API alerts
Same action chains as the rest of the platform
Audit of every breach and every resolution

Manager
Worker
Cache
Log
Threshold + duration

Four component health panels in a two-by-two grid — Manager, Gateway Worker, Cache, and Log — each showing CPU and memory progress bars with current value against a threshold and a duration window pinned underneath; a header reads each panel as "over threshold for duration" rules, and a footer card pins the action-on-breach configuration.

05 · Action chains

Right person. Right channel. Right now.

Severity decides where the alarm goes — P1 to on-call, P3 to the daily digest — across nine action types and fifteen-plus connectors.

Severity-aware routing · P1 to on-call, P3 to digest
Nine action types · email, webhook, API, DB, script, SNMP
Connector library · Slack, Teams, ServiceNow, and 15+ more
Grouping, deduplication, acknowledgment, escalation
Acknowledge from Slack — no context switch

Slack · Teams
ServiceNow · Email
Webhook · API · DB
Script · SNMP
Group · dedup · escalate

06 · Severity + history

Four grades. Every probe stored. Full audit.

Info, warning, error, critical — every detection is graded, grouped, deduplicated, and audited. Retention is configurable per surface; exports go straight to PDF, CSV, or Excel.