Sentry-Anrufalarme für produktionskritische Fehler

Inhaltsverzeichnis

• Warum Sentry Ihr Telefon nicht selbst klingeln lässt
• Was Sie brauchen
• Schritt 1 — Einen Kanal anlegen, der klingelt
• Schritt 2 — Eine interne Sentry-Integration erstellen
• Schritt 3 — Die Integration als Regel-Aktion hinzufügen
• Schritt 4 — Wissen, was wirklich ankommt
• Schritt 5 — Auf das reduzieren, was einen Anruf verdient
• Schritt 6 — Warnungen bekommen eine leisere Tür
• Nur außerhalb der Arbeitszeit klingeln
• Die zwei Fallen
• Payload-Größe, Fehlerstürme und Kürzung
• Mit dem Team teilen
• Was dieses Setup nicht leistet
• Fehlersuche
• Häufige Fragen
• Kann Sentry nativ anrufen?
• Durchbricht ein Sentry-Alert „Nicht stören“?
• Brauche ich für Webhooks einen kostenpflichtigen Sentry-Plan?
• Warum ist meine Template-Variable leer?
• Wie alarmiere ich nur für eine Umgebung?
• Können zwei Personen für denselben Fehler angerufen werden?
• Filtern in Sentry oder in Echobell?
• Fazit
• Verwandte Artikel

Sentry kann Sie nicht anrufen. Es kann eine E-Mail schicken, in Slack posten oder den Alert an PagerDuty übergeben – eine eingebaute Sprach-Aktion gibt es aber nicht. Der Weg zu einer solchen, ohne eine Incident-Plattform zu kaufen: Sie schicken den Sentry-Issue-Alert an einen Webhook, der klingelt. Interne Integration anlegen, auf einen Echobell-Anrufkanal zeigen lassen, und davor einen Filter setzen, damit nur Fehler durchkommen, die wirklich die Produktion brechen.

Dieser Leitfaden deckt den ganzen Weg ab: die Integration, die Alert-Regel, das tatsächlich gesendete Payload, die Templates, die es lesen, und die zwei Fallen, an denen die meisten aufgeben.

Warum Sentry Ihr Telefon nicht selbst klingeln lässt

Die Aktionen von Sentrys Issue-Alerts umfassen Benachrichtigungen (E-Mail, Slack, Discord, Microsoft Teams), Ticket-Erstellung (Jira, GitHub, Azure DevOps) und die Übergabe an ein Paging-Produkt (PagerDuty, Opsgenie). Jede davon endet auf einem Bildschirm, auf den Sie gerade schauen müssen – oder auf einem kostenpflichtigen Platz bei einem anderen Anbieter.

Um 14 Uhr ist das in Ordnung. Um 3 Uhr nachts ist eine Slack-Nachricht nicht von Stille zu unterscheiden, und eine Push-Benachrichtigung verliert gegen „Nicht stören“. Für die kleine Menge an Fehlern, bei denen zwei Stunden Verzögerung echtes Geld kosten – der Checkout liefert 500er, die Authentifizierung weist jeden Login ab, ein Worker verwirft Jobs stillschweigend – brauchen Sie ein Gerät, das klingelt.

Der Webhook ist die Nahtstelle. Sentry kann als Aktion einer Alert-Regel einen beliebigen HTTPS-Endpunkt aufrufen; Echobell verwandelt diesen HTTP-Request in einen anrufartigen Alarm, der den iOS-Fokus durchbricht.

Was Sie brauchen

• Eine Sentry-Organisation, in der Sie Settings → Developer Settings erreichen (Owner oder Manager)
• Echobell installiert (App Store / Google Play)
• Fünf Minuten

Auf Ihrer Seite muss nichts aus dem Internet erreichbar sein. Sentry stellt die ausgehende Anfrage; Sie empfangen sie nur.

Schritt 1 — Einen Kanal anlegen, der klingelt

Legen Sie in Echobell einen Kanal an und setzen Sie den Benachrichtigungstyp auf Anruf. Genau darum geht es: Ein Anrufkanal verhält sich wie ein eingehender Anruf statt wie ein Push und kommt damit durch Fokus und „Nicht stören“.

Geben Sie ihm Templates, die um 3 Uhr nachts Sinn ergeben. Sentrys Payload ist tief verschachtelt, die Variablenpfade sind also länger als gewohnt:

Titel: {{data.event.level}}: {{data.event.metadata.type}}
Text: {{data.event.title}} — {{data.event.culprit}}

Setzen Sie in den erweiterten Einstellungen das Link-Template, damit ein Tippen auf die Benachrichtigung das Issue öffnet:

{{data.event.web_url}}

Kopieren Sie die Webhook-URL aus der Kanaldetailansicht. Sie sieht so aus:

https://hook.echobell.one/t/<channel-token>

Schritt 2 — Eine interne Sentry-Integration erstellen

Sentry bietet einen Webhook als Alert-Regel-Aktion nur über eine Integration an, also müssen Sie eine anlegen. Das ist ein Formular, kein Dienst – Sie schreiben keinen Code.

1. Gehen Sie zu Settings → Developer Settings → Custom Integrations
2. Create New Integration → Internal Integration
3. Name: Echobell (das ist die Bezeichnung, die Sie später in der Regel auswählen)
4. Webhook URL: Ihre Kanal-URL aus Schritt 1
5. Schalten Sie Alert Rule Action ein
6. Permissions: Issue & Event → Read genügt
7. Lassen Sie unter Webhooks alle Kästchen leer – siehe die Falle weiter unten
8. Speichern

Eine interne Integration gilt nur für Ihre Organisation und installiert sich selbst. Das erzeugte Token brauchen Sie für dieses Setup nie.

Schritt 3 — Die Integration als Regel-Aktion hinzufügen

Gehen Sie zu Alerts → Create Alert → Issue Alert oder bearbeiten Sie eine bestehende Regel.

Fügen Sie unter Then perform these actions die Aktion Send a notification via an integration hinzu und wählen Sie Echobell.

Setzen Sie Action interval – die Drosselung für „wenn dieser Alert mehr als einmal ausgelöst hat“ – auf mindestens 30 minutes. Die Voreinstellung sendet bei jedem Auslösen, und ein Fehler, der 400-mal pro Minute feuert, wählt sonst Ihre Nummer, bis Sie abschalten.

Speichern Sie und lösen Sie den Test der Regel aus, damit Sie ein echtes Payload ankommen sehen, bevor Sie sich darauf verlassen.

Schritt 4 — Wissen, was wirklich ankommt

Hier scheitern die meisten Setups, denn das Payload hat nicht die Form, die man vermutet. Sentry verpackt alles:

{
  "action": "triggered",
  "actor": { "id": "sentry", "name": "Sentry", "type": "application" },
  "data": {
    "event": {
      "event_id": "e4874d664c3540c1a32eab185f12c5ab",
      "level": "error",
      "title": "ReferenceError: heck is not defined",
      "culprit": "?(<anonymous>)",
      "platform": "javascript",
      "project": 1,
      "release": null,
      "metadata": { "type": "ReferenceError", "value": "heck is not defined" },
      "tags": [["level", "error"], ["browser", "Chrome 75.0.3770"]],
      "issue_id": "1117540176",
      "issue_url": "https://sentry.io/api/0/issues/1117540176/",
      "web_url": "https://sentry.io/organizations/test-org/issues/1117540176/events/e4874.../"
    },
    "triggered_rule": "Very Important Alert!"
  },
  "installation": { "uuid": "a8e5d2..." }
}

Vier Dinge, die Sie vor dem ersten Template wissen sollten:

• Alles Nützliche liegt unter data.event. {{title}} rendert nichts; {{data.event.title}} rendert den Fehler.
• data.event.project ist eine numerische ID, kein Slug. Wenn Sie einen lesbaren Projektnamen in der Benachrichtigung wollen, schreiben Sie ihn als festen Text ins Titel-Template und nutzen Sie einen Kanal pro Projekt.
• Es gibt kein Feld environment. Die Umgebung kommt in data.event.tags als Paar ["environment", "production"] an, und ihre Position im Array ist nicht stabil – greifen Sie also nicht per Index darauf zu. Filtern Sie die Umgebung in der Sentry-Regel (Schritt 5).
• data.triggered_rule ist der Regelname. Nützlich im Text, wenn ein Kanal mehrere Regeln bedient.

Der Header Sentry-Hook-Resource lautet bei Issue-Alerts event_alert. Sie können ihn in einer Kanalbedingung verlangen, damit nichts anderes den Kanal klingeln lässt:

header["sentry-hook-resource"] == "event_alert"

Schritt 5 — Auf das reduzieren, was einen Anruf verdient

Ein Anrufkanal, der bei jedem neuen Issue klingelt, ist schlimmer als gar kein Kanal: Nach einer Woche haben Sie ihn stummgeschaltet – und dann klingelt er auch nicht bei dem einen, der zählte. Filtern Sie an zwei Stellen.

In Sentry über die Conditions und Filters der Regel:

In Echobell dient eine Kanalbedingung als Auffangnetz für das, was Sentry nicht ausdrücken kann, oder für Änderungen, die Sie heute nicht mehr ausrollen können:

data.event.level == "fatal" || data.event.level == "error"

Die Schwere in der Sentry-Regel zu filtern ist meist besser, weil dort auch die Drosselung sitzt. In Echobell zu filtern ist besser, wenn Sie aus einer Sentry-Regel zwei Dringlichkeitsstufen gewinnen wollen.

Schritt 6 — Warnungen bekommen eine leisere Tür

Der Sinn der Stufen ist, dass der Anruf seine Bedeutung behält. Legen Sie einen zweiten Echobell-Kanal vom Typ Zeitkritisch an, fügen Sie eine zweite Sentry-Regel mit niedrigerer Schwelle hinzu und zeigen Sie damit auf eine zweite interne Integration (eine Integration trägt genau eine Webhook-URL, ein zweiter Kanal braucht also eine zweite Integration).

Ein Setup, das eine echte Woche übersteht, sieht ungefähr so aus:

Nur außerhalb der Arbeitszeit klingeln

Tagsüber schauen Sie ohnehin auf Sentry. Echobell stellt Bedingungen UTC-Systemzeitvariablen bereit, sodass sich ein Kanal ohne zweite Sentry-Regel je nach Stunde anders verhalten kann:

data.event.level == "fatal" && (hour >= 17 || hour < 9)

Ergänzen Sie eine Wochentagsprüfung, wenn Ihr Wochenende wirklich frei ist:

data.event.level == "fatal" && (hour >= 17 || hour < 9 || dayOfWeek == 0 || dayOfWeek == 6)

Alles davon ist UTC – rechnen Sie also aus Ihrer Zeitzone um, bevor Sie die Zahlen festschreiben. Die Bedingungsreferenz enthält die vollständige Variablenliste.

Die zwei Fallen

Falle 1: die Webhooks-Kästchen ankreuzen. Eine interne Integration hat zwei unabhängige Webhook-Pfade. Der Schalter Alert Rule Action macht die Integration in Alert-Regeln auswählbar – den wollen Sie. Die Webhooks-Kästchen (issue, error, comment) abonnieren jedes Ereignis der jeweiligen Ressource: jedes erstellte, gelöste, zugewiesene, archivierte oder ignorierte Issue in der ganzen Organisation. Kreuzen Sie issue an, klingelt Ihr Telefon, wenn ein Kollege etwas löst. Lassen Sie alle leer, feuern nur Ihre Alert-Regeln den Webhook.

Falle 2: das alte Webhooks-Plugin nutzen. Das alte projektbezogene Plugin Legacy Integrations → WebHooks existiert weiterhin und funktioniert auch, und es wirkt wie eine Abkürzung, weil man eine URL einfügen kann, ohne eine Integration anzulegen. Sein Payload hat eine andere, flachere Form, seine Requests sind nicht signiert, und Sentry lenkt neue Setups davon weg. Wenn Sie es verwenden, brauchen Ihre Templates andere Variablenpfade als die oben. Nehmen Sie die interne Integration.

Payload-Größe, Fehlerstürme und Kürzung

Drei Grenzen, die man kennen sollte, bevor im großen Maßstab etwas schiefgeht:

• 1 MiB Body. Echobell weist Trigger-Bodies über 1 MiB mit HTTP 413 ab. Ein Sentry-Payload trägt den vollständigen Stacktrace und den Request-Kontext, landet also üblicherweise im zweistelligen Kilobyte-Bereich – ein Event mit großem Request-Body kann aber nah herankommen. Auf Sentry-Seite gibt es kein max_alerts; die Gegenmaßnahme ist, große Request-Bodies im beforeSend Ihres SDK zu bereinigen, was Sie aus Datenschutzgründen ohnehin wollen.
• 120 Anfragen pro Minute und Token. Darüber antwortet der Trigger mit 429, RATE_LIMIT_EXCEEDED und einem Retry-After. Sentrys Action interval hält Sie darunter; 30 minutes reicht reichlich.
• 1500 Bytes Benachrichtigungstext. Längeres wird gekürzt, bevor es das Gerät erreicht. data.event.title plus culprit passt bequem; data.event.exception hineinzukippen nicht – und auf einem Sperrbildschirm ist es ohnehin unlesbar. Lassen Sie die Details hinter dem Link-Template.

Mit dem Team teilen

Einen Echobell-Kanal können mehrere Personen abonnieren, und jede wählt ihren eigenen Benachrichtigungstyp. Dieselbe Sentry-Regel kann so das Telefon der Person in Rufbereitschaft klingeln lassen und bei allen anderen als gewöhnlicher Push ankommen – ohne Preis pro Platz, ohne Rotationskonfiguration.

Was es nicht ist: eine Eskalationsrichtlinie. Es gibt kein „wenn in fünf Minuten niemand bestätigt, ruf die nächste Person an“. Wenn Sie das brauchen, brauchen Sie eine echte On-Call-Plattform; Echobell deckt die Zustellschicht darunter ab.

Was dieses Setup nicht leistet

Sagen wir es deutlich:

• Keine Bestätigung. Den Anruf anzunehmen teilt Sentry nichts mit und stoppt die Telefone der anderen Abonnenten nicht.
• Keine Rotation, keine Eskalation. Entweder bekommen es alle Abonnierten oder niemand.
• Keine Deduplizierung über Sentry hinaus. Gruppierung und Drosselung passieren in der Regel; Echobell stellt zu, was ankommt.
• Keine Zwei-Wege-Synchronisierung. Das Issue in Sentry zu lösen räumt auf Ihrem Telefon nichts auf.

Wenn das Ausschlusskriterien sind, ist dies das falsche Werkzeug. Wenn Sie tatsächlich „weck mich, wenn der Checkout bricht“ brauchen, ist es ungefähr der günstigste verlässliche Weg dorthin.

Fehlersuche

Die Regel feuert, aber nichts kommt an. Prüfen Sie, ob Alert Rule Action in der Integration aktiv ist. Ist es aus, erscheint die Integration gar nicht erst in der Aktionsliste – und eine vorher gespeicherte Regel behält die veraltete Aktion.

Eine Benachrichtigung kommt an, ist aber leer. Ihr Template liest Schlüssel der obersten Ebene. Sentry verschachtelt alles unter data.event.

Es klingelt bei Unerwartetem. Prüfen Sie die Webhooks-Kästchen der Integration (Falle 1) und dann, ob die Umgebung der Regel auf „All Environments“ steht.

Es klingelt wiederholt für denselben Fehler. Erhöhen Sie das Action interval der Regel. Echobells Wiederholung ist etwas anderes: Fehlgeschlagenen Anruf wiederholen in den App-Einstellungen wählt einen verpassten Anruf erneut.

Es kommt nie etwas an, nicht einmal der Test. Lösen Sie den Kanal zuerst mit curl aus, um die Echobell-Seite auszuschließen:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H 'Content-Type: application/json' \
  -d '{"data":{"event":{"level":"fatal","title":"Test error","culprit":"manual test","metadata":{"type":"TestError"}}}}'

Klingelt das und Sentry nicht, liegt das Problem in der Integration, nicht im Kanal.

Häufige Fragen

Kann Sentry nativ anrufen?

Nein. Sentrys Issue-Alert-Aktionen sind Benachrichtigungen, Ticket-Erstellung und Integrationen mit Paging-Produkten. Ein Sprachanruf erfordert einen externen Dienst – entweder eine Paging-Plattform wie PagerDuty oder einen Webhook-Empfänger, der klingelt, wie Echobell.

Durchbricht ein Sentry-Alert „Nicht stören“?

Nur wenn er als anrufartiger Alarm ankommt. Ein Echobell-Kanal vom Typ Anruf verhält sich wie ein eingehender Anruf, und den lassen iOS-Fokus und „Nicht stören“ durch. Ein gewöhnlicher Push aus irgendeiner App nicht.

Brauche ich für Webhooks einen kostenpflichtigen Sentry-Plan?

Interne Integrationen und Alert-Regel-Aktionen sind ab Sentrys Developer-Plan verfügbar. Der Webhook selbst kostet nichts extra.

Warum ist meine Template-Variable leer?

Fast immer, weil der Pfad zu kurz ist. Das Alert-Payload verschachtelt das Event unter data.event, es heißt also {{data.event.title}}, nicht {{title}}. Lösen Sie den Kanal einmal aus und prüfen Sie den aufgezeichneten Request-Body in der App, um die genaue Form zu sehen.

Wie alarmiere ich nur für eine Umgebung?

Setzen Sie das Feld Environment in der Sentry-Alert-Regel. Versuchen Sie nicht, es aus data.event.tags zu lesen – das ist ein Array aus [Schlüssel, Wert]-Paaren ohne garantierte Reihenfolge.

Können zwei Personen für denselben Fehler angerufen werden?

Ja. Teilen Sie den Kanal und lassen Sie jede Person mit dem gewünschten Benachrichtigungstyp abonnieren. Da es keine Bestätigung gibt, werden alle angerufen, die „Anruf“ gewählt haben.

Filtern in Sentry oder in Echobell?

In Sentry, wo es geht – dort sitzen auch Drosselung und Umgebungsbegrenzung. In Echobell, wenn Sie aus einer Regel zwei Dringlichkeitsstufen wollen, ein Zeitfenster brauchen oder die Regel heute nicht geändert werden kann.

Fazit

Das Setup besteht aus vier Dingen: einem Anrufkanal, einer internen Integration mit aktivem Alert Rule Action und leeren Webhooks-Kästchen, einer Alert-Regel, die eng genug ist, um einen Anruf zu verdienen, und Templates, die data.event lesen. Alles andere auf dieser Seite dient dazu, sie eng genug zu halten, damit das Klingeln in einem Monat noch etwas bedeutet.

Echobell für iPhone laden oder bei Google Play holen – und schicken Sie das curl von oben, bevor Sie diesem Pfad etwas wirklich Wichtiges anvertrauen.

Verwandte Artikel

• Referenz der Kanalbedingungen
• Leitfaden zur Webhook-Integration
• Entwicklerleitfaden gegen Alert-Müdigkeit
• Telefonalarme mit Prometheus Alertmanager
• iOS-Fokus für kritische Alarme durchbrechen