Get phone and SMS alerts fromMetoro
Metoro is an eBPF observability platform for Kubernetes, and its alerts fire the moment a metric, a log pattern, a trace or a cluster resource leaves the range you set. Spike turns every firing Metoro alert into an incident and pages the engineer on call — by phone, SMS, Slack or email — escalating until someone acknowledges it.
Set up with AI
I use Metoro for monitoring and Spike for on-call and incident management. Walk me through connecting them: create a Metoro integration in Spike, copy its webhook URL, and add that webhook to Metoro alert settings. Then help me send a test alert to confirm incidents show up in Spike.
What is Metoro?
Metoro installs as a DaemonSet from a single Helm command and collects its telemetry with eBPF, in the kernel, so there is no SDK to add, no code to change and no container to restart. Request rates, error rates and latencies for every service, utilisation and saturation for every node, container logs, distributed traces, continuous CPU and memory profiles, Kubernetes events, and the versioned history of your deployments and ConfigMaps all arrive already tagged with the workload, namespace and cluster they came from. Alerts sit on top of that data — metric, log, trace and Kubernetes resource alerts, written in the Alerts UI or declared as MetoroAlert resources alongside the service they watch — and Metoro’s Guardian agents investigate what they find.
A firing alert is visible in Metoro, and visibility is not the same as someone answering it. Connected to Spike, each one becomes an incident: Spike phones and texts whoever is on call, and if nobody acknowledges it, the escalation policy hands it to the next responder.
Spike keys the incident on the uuid of the firing, not on the alert rule, which is what keeps a busy alert readable. Repeat notifications about the same firing join the incident that is already open rather than paging again, and an alert that groups by service or namespace opens one incident per group — the checkout-api breach and the ledger-api breach stay two separate pages for two separate problems, instead of collapsing into one. When the alert recovers, Metoro sends the recovery to the same webhook carrying the same uuid, and the incident it opened resolves itself.
The incident takes its title from the alert’s own description — “checkout-api is returning 5xx on more than 2% of requests for the last 5 minutes” — which is all a locked phone screen needs to show, cut at a word boundary past 200 characters. Where a description was never written, Spike builds the line instead, out of the rule’s name, the metric that breached, its last value and the service or environment it fired for: “checkout-api 5xx rate high — http.server.request.count 4.7 on checkout-api (production)”. The deep link back into Metoro travels with the incident, so the alert is one tap away from the page that woke you. Metoro sends no severity of its own, so severity is Spike’s to decide: an alert routing rule reads each incoming alert and sets how serious the incident is, who it reaches, and whether it should page at all — the same rules that sort what arrives from Prometheus or Grafana, so a cluster watched by more than one tool still pages one rotation.
How to set up Metoro alerts
A Spike integration is a unique webhook URL. Add it as a webhook in Metoro, paste Spike's body template into it, and point your alerts at it — firing and recovering.
Step 1: Create a Metoro integration in Spike
In your Spike dashboard, open Integrations and choose Metoro. Spike generates a unique webhook URL for this integration — copy it, and attach the integration to the service and escalation policy that should answer what Metoro finds.
Step 2: Add the webhook in Metoro
In Metoro, go to Integrations and add a webhook. Name it, paste the Spike URL into the URL field, and leave the HTTP method on POST and the headers empty — the token in the Spike URL is the credential, so no extra authentication header is needed.
Step 3: Paste Spike's body template
Metoro posts whatever JSON you type into Body Template, substituting its own variables, so the template is what decides how much Spike can read. Take the template from Spike's Metoro guide — the documentation link on the integration you just created — and paste it in as it stands. Three of its lines carry the behaviour — state tells Spike whether the alert is firing or recovering; alert_fire_uuid keeps every notification about one firing on one incident; and description gives the incident its title.
Step 4: Point an alert at it, firing and recovering
Open the alert you want to page on, and under Select Destination choose Add Destination, then Webhook, and pick the webhook you just made. Tick Notify when alarm recovers and pick the same webhook in the second selector that appears — that recovery notification is what closes the incident. Metoro has no test-webhook button, so confirm the wiring with a real alert.
That's it — Metoro alerts now page whoever is on call.
