Rufbereitschaft-Einstellungen | kanman Dokumentation

Einstellungen eines Service unter Services > (Service) > Rufbereitschaft. Inhaber und Admins ändern sie, Mitglieder sehen sie. Jede Änderung steht im Audit-Log (Ereignis „Service geändert“).

Einstellungen

Einstellung	Werte	Standard	Wirkung
Nur beobachten	an, aus	aus	Harter Schalter. An: kanman eröffnet Incidents, untersucht, postet und benachrichtigt, startet aber nie einen Fix, schlägt nie einen Revert vor und ändert nie einen Alarm in Ihrem Tool.
Dringende Fixes selbst starten	an, aus	aus	Bei einem Incident mit Ursache im Code ohne verdächtigen Merge. An: kanman legt eine dringende Story an und startet den Fix. Aus: Es fragt zuerst unter Entscheidungen („Dringenden Fix starten“ oder „Der Person in Rufbereitschaft überlassen“).
Alarme in der Quelle bestätigen und auflösen	an, aus	aus	PagerDuty und Opsgenie mit API-Zugangsdaten: kanman bestätigt den Alarm, wenn es mit der Untersuchung beginnt, und löst ihn auf, wenn Sie den Incident in kanman auflösen. Aus: kanman fasst den Alarm nie an.
Niedrigster Schweregrad, der einen Incident eröffnet	Kritisch, Hoch, Mittel, Niedrig, Info	Hoch	Niedrigere Alarme werden bei der Quelle erfasst, eröffnen aber keinen Incident. Alarme zu einem offenen Incident kommen immer dazu.
Rufbereitschaftszeiten für kanman	Immer, oder Tage, Beginn, Ende und Zeitzone	Immer	Außerhalb der Zeiten erfasst kanman Alarme, eröffnet aber keinen Incident. Zeitfenster über Mitternacht (zum Beispiel 22:00 bis 06:00) sind möglich.
Wer benachrichtigt wird	Mitglieder des Workspaces	niemand	Jede Person erhält in kanman eine Benachrichtigung, wenn ein Incident eröffnet und wenn er aufgelöst wird, und wird im Incident-Post genannt.
Incident-Orte	Die Orte des Teams in Slack und Microsoft Teams	alle Kanäle des Teams	Wo Incidents gepostet werden, ein Thread pro Ort. Orte werden in den Kommunikationseinstellungen des Teams hinzugefügt.

Änderungen in Produktion außerhalb des Codes sind nie einstellbar: kanman fragt immer einen Menschen.

Schweregrade

Die Stufen der Alarmierungstools werden auf die fünf Schweregrade von kanman abgebildet:

kanman	Beispiele aus Tools
Kritisch	`critical`, P1, SEV1, Sev0 (Azure), „major outage“ (Statuspage), `[critical]` in einer CloudWatch-Alarmbeschreibung
Hoch	`high`, `error`, P2, Sev1 (Azure), „partial outage“, CloudWatch-Alarme ohne Angabe
Mittel	`warning`, P3, Sev2 (Azure), „degraded performance“, unbekannte Werte
Niedrig	`low`, `minor`, P4, Sev3 (Azure)
Info	`info`, P5, Sev4 (Azure), Wartung

Allgemeines Alarmformat

Senden Sie POST-Anfragen mit einem JSON-Body an die Webhook-URL der Quelle. Einen Alarm, oder mehrere unter alerts:

{
  "fingerprint": "checkout-5xx",
  "status": "firing",
  "severity": "critical",
  "title": "Checkout returns 500",
  "description": "Error rate above 5% for 5 minutes",
  "service": "checkout",
  "environment": "production",
  "startedAt": "2026-10-01T10:00:00Z",
  "labels": { "region": "eu" },
  "links": [{ "label": "Runbook", "url": "https://runbooks.example.com/checkout" }]
}

Feld	Pflicht	Bedeutung
`title`	ja	Kurze Beschreibung, Titel des Incidents
`status`	nein	`firing` (Standard) oder `resolved`
`fingerprint`	nein	Identität des Alarms. Ein `resolved`-Alarm mit demselben Fingerprint erholt ihn. Standard: `id`, sonst ein Hash aus Titel und Labels
`id`	nein	Ihre ID des Alarms
`severity`	nein	Siehe Schweregrade; Standard mittel
`service`	nein	Wählt den Service, wenn die Quelle mehrere speist (Abgleich mit dem Namen des Service)
`description`, `environment`, `startedAt`, `endedAt`, `labels`, `links`	nein	Werden beim Incident angezeigt

Signatur

Signieren Sie den exakten Request-Body mit dem Secret der Quelle, HMAC-SHA256, hexadezimal:

X-Kanman-Signature: sha256=<HMAC-SHA256 des Bodys, hexadezimal>

Zum Schutz vor Wiederholungen senden Sie zusätzlich X-Kanman-Timestamp: <Unix-Sekunden> und signieren stattdessen <Zeitstempel>.<Body>; kanman lehnt dann Anfragen ab, die älter als fünf Minuten sind.

Beispiel mit curl und openssl:

BODY='{"fingerprint":"checkout-5xx","status":"firing","severity":"critical","title":"Checkout returns 500"}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$KANMAN_SOURCE_SECRET" -hex | sed 's/^.* //')
curl -X POST "https://api.kanman.ai/functions/v1/signal-webhook/<Quell-Token>" \
  -H "Content-Type: application/json" -H "X-Kanman-Signature: sha256=$SIG" -d "$BODY"

Wie kanman Webhooks prüft

Tool	Was kanman erwartet
Allgemeines Format	`X-Kanman-Signature` (oben)
Grafana	HMAC-Signatur-Header des Kontaktpunkts, oder `Authorization: Bearer <Secret>`
PagerDuty	`X-PagerDuty-Signature`, erstellt mit dem Signing-Secret des Abos
Sentry	`Sentry-Hook-Signature`, erstellt mit dem Client-Secret der Integration
Alertmanager, Datadog, New Relic, Opsgenie	`Authorization: Bearer <Secret>` oder `X-Kanman-Token: <Secret>`
CloudWatch, Azure Monitor, Statuspage	`?key=<Secret>` in der URL; bei CloudWatch zusätzlich eine gültige AWS-Signatur auf jeder Nachricht

Anfragen ohne den richtigen Nachweis werden mit Status 401 abgelehnt, unbekannte Adressen mit 404. Angenommene Anfragen werden mit 202 beantwortet. Payloads über 512 KB werden abgelehnt.

Audit-Ereignisse

Ereignis	Wann
Service geändert	Ein Service oder seine Rufbereitschaft wurde angelegt, geändert oder gelöscht
Signalquelle geändert	Eine Quelle wurde hinzugefügt, geändert, pausiert, gelöscht oder ihr Secret erneuert
Signal empfangen	Eine Lieferung eines Alarmierungstools oder ein fehlschlagender oder erholter Uptime-Check
Incident eröffnet, aktualisiert, aufgelöst	Der Lebenszyklus des Incidents, einschließlich der dringenden Fixes, die kanman gestartet hat
Alarm in der Quelle aktualisiert	kanman hat einen Alarm in PagerDuty oder Opsgenie bestätigt oder aufgelöst

Siehe Format des Audit-Exports.