Skip to content

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

  1. Alertmanager running — already deployed and firing alerts. We'll add KubeManta as a receiver.
  2. Network path — Alertmanager must reach KubeManta's webhook URL (typically https://kubemanta.example.com/api/agent/integrations/alertmanager/webhook for internet-facing, or an internal hostname if on the same network).
  3. 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:

  1. In the sidebar, click Admin (gear icon).
  2. Open the Observability tab.
  3. Under Configure sources, select Alertmanager from the dropdown.
  4. A receiver secret is auto-generated; copy it (you'll paste it into Alertmanager next).
  5. 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).
  6. 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

  1. Click Activity in the sidebar (or Overview → scroll to activity feed).
  2. You should see a Filters section with an alert-count indicator.
  3. 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:

amtool alert add test severity=critical

Then refresh the KubeManta Activity feed — you should see it appear.

Check KubeManta logs

kubectl logs -n kubemanta-system deploy/kubemanta-agent | grep observability

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:

  1. No extra configuration needed — if AI is enabled and a critical alert fires, the copilot will run a silent investigation.
  2. Results flow to Slack — optionally configure a Slack webhook in Alerts Manager → Integrations to post the investigation summary.
  3. 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?

amtool alert
# should show active alerts

If none, fire a test:

amtool alert add test severity=critical

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:

kubectl logs -n kubemanta-system deploy/kubemanta-agent | grep -i alert

"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.