Alertmanager¶
Connect your Prometheus Alertmanager so its alerts flow into KubeManta's activity feed and alert history, and optionally trigger automatic investigation by the AI copilot.
What it gives you¶
- Centralized alert view — all Alertmanager firings appear in KubeManta's Activity feed alongside cluster events
- Alert history — searchable, sortable, persisted in KubeManta (by default for 180 days)
- AI auto-investigation — when a critical alert fires (Pro + AI enabled), KubeManta can automatically diagnose the issue and post results to Slack
- De-duplication — same alert from multiple sources doesn't spam the feed
Tier: Free (ingestion + view); Pro (auto-investigation)
Prerequisites¶
- Alertmanager running — already deployed and firing alerts. We'll add KubeManta as a receiver.
- Network path — Alertmanager must reach KubeManta's webhook URL (typically
https://kubemanta.example.com/api/agent/integrations/alertmanager/webhookfor internet-facing, or an internal hostname if on the same network). - A receiver secret — KubeManta will generate a unique secret to authenticate incoming webhooks (so only your Alertmanager can deliver alerts to you).
Configure in KubeManta¶
Step 1 — Generate a receiver secret¶
In KubeManta:
- In the sidebar, click Admin (gear icon).
- Open the Observability tab.
- Under Configure sources, select Alertmanager from the dropdown.
- A receiver secret is auto-generated; copy it (you'll paste it into Alertmanager next).
- Your webhook URL is displayed — copy that too (it will include the token in the query string for reference, but Alertmanager uses the secret in the body).
- Click Save.
Both the secret and URL are stored encrypted at rest.
Step 2 — Configure Alertmanager to send to KubeManta¶
In your Alertmanager config:
receivers:
- name: kubemanta
webhook_configs:
- url: https://kubemanta.example.com/api/agent/integrations/alertmanager/webhook
send_resolved: false
Add the secret as a header by replacing the simple url: above with:
receivers:
- name: kubemanta
webhook_configs:
- url: https://kubemanta.example.com/api/agent/integrations/alertmanager/webhook
send_resolved: false
headers:
Authorization: "Bearer YOUR_RECEIVER_SECRET"
Or, if your Alertmanager version supports query parameters in the webhook URL, append the token:
receivers:
- name: kubemanta
webhook_configs:
- url: https://kubemanta.example.com/api/agent/integrations/alertmanager/webhook?token=YOUR_RECEIVER_SECRET
send_resolved: false
Step 3 — Route alerts to the receiver¶
Add a route in your Alertmanager config to send the alerts you care about to KubeManta:
global:
resolve_timeout: 5m
route:
receiver: default
routes:
- receiver: kubemanta
match:
severity: "critical" # Send only critical alerts, or remove match to send all
Reload Alertmanager:
kubectl rollout restart -n monitoring statefulset/alertmanager
# or: amtool config routes (to reload without restarting)
Verify¶
Quick check in the UI¶
- Click Activity in the sidebar (or Overview → scroll to activity feed).
- You should see a Filters section with an alert-count indicator.
- If an alert just fired in Alertmanager, it should appear in the feed within seconds.
Test with amtool¶
If you have amtool installed, send a test alert:
Then refresh the KubeManta Activity feed — you should see it appear.
Check KubeManta logs¶
Look for messages confirming the webhook was received.
Expected states¶
| State | Meaning | Next step |
|---|---|---|
| No alerts in Activity feed | Either no alerts have fired, or Alertmanager hasn't reached KubeManta yet | Fire a test alert with amtool, or check logs for webhook errors |
| Alerts appear in the feed | Success! | (Optional) Enable AI auto-investigation if you have Pro + AI |
| Alerts appear but seem stale | Alertmanager may be sending old firings due to grouping or timing | Check your Alertmanager config's group_wait / group_interval |
Auto-investigation (optional, Pro + AI)¶
When you have a Pro license and AI enabled, KubeManta can automatically investigate critical alerts:
- No extra configuration needed — if AI is enabled and a critical alert fires, the copilot will run a silent investigation.
- Results flow to Slack — optionally configure a Slack webhook in Alerts Manager → Integrations to post the investigation summary.
- You can disable it — in Admin → AI Guardrails, toggle "Autonomous investigation of critical alerts" off if you prefer manual investigation.
Troubleshooting¶
Alerts not appearing in KubeManta¶
Is Alertmanager actually firing alerts?
If none, fire a test:
Is the webhook URL reachable from Alertmanager? - For in-cluster Alertmanager: can it reach KubeManta's cluster IP / service DNS? - For external Alertmanager: can it reach your KubeManta hostname over HTTPS?
Try a test webhook POST:
curl -X POST \
-H "Authorization: Bearer YOUR_RECEIVER_SECRET" \
-H "Content-Type: application/json" \
-d '{"alerts":[{"labels":{"alertname":"TestAlert","severity":"critical"},"status":"firing"}]}' \
https://kubemanta.example.com/api/agent/integrations/alertmanager/webhook
Check KubeManta logs for webhook errors:
"Webhook signature invalid" or "unauthorized" error¶
Did you copy the secret correctly? Double-check it character-for-character in the Authorization header.
Is the secret still the same? If you regenerated the secret in KubeManta, update Alertmanager's config with the new one.
Check the timestamp — KubeManta verifies the webhook timestamp is recent (within a few minutes). If your system clocks are skewed between Alertmanager and KubeManta, sync them.
Alerts are duplicated in the feed¶
Alertmanager sends the same alert every group_interval (default 5 minutes). KubeManta de-duplicates by alert group, but you may still see re-sends as separate rows if the alert is re-grouped. This is expected behavior.
Related¶
- Activity & Audit — the full audit trail + export
- Alerts feature — KubeManta's own rules engine
- Observability connector — network security + webhook setup details
- Install → Network access — ensure Alertmanager can reach your KubeManta hostname