So funktioniert Honk

Dein Shop, deine Formulare, dein Zuhause und deine Server sagen Honk, was passiert ist. Honk bewahrt jede Nachricht auf, fasst Wiederholungen zusammen, pusht nur, was nicht warten kann, und legt den Rest in einen Posteingang, den du liest, wann du willst.

Von der Anfrage zum Push

  1. Anfrage Dein Code sendet JSON mit dem Ingest-Schlüssel eines Projekts an /v1/messages.
  2. Gespeichert Honk schreibt die Nachricht auf die Festplatte und antwortet erst dann mit 202. Kommt sie mit demselben Idempotency-Key noch einmal, gibt es dieselbe ID zurück, keine zweite Nachricht.
  3. Gruppiert Sie landet in der Gruppe, die zu Projekt, Umgebung, Quelle, Kanal und group_key passt.
  4. Verteilt Für jede Person entscheidet Honk: sofort pushen, für die Zusammenfassung sammeln oder nur im Posteingang behalten.
  5. Gesendet Pushes gehen über Apples Push-Dienst und Web Push raus. Im Posteingang bleibt alles durchsuchbar.

202 heißt: Honk hat die Nachricht. Gesehen hat sie damit noch niemand. Deshalb sagen die Apps nie „zugestellt“: Apple und die Push-Dienste der Browser bestätigen nur, dass sie eine Mitteilung angenommen haben.

Gruppen und Episoden

Eine Gruppe sammelt die Ereignisse, die dieselbe Sache betreffen. Zwei Ereignisse gehören zur selben Gruppe, wenn sie aus demselben Projekt, derselben Umgebung, Quelle und demselben Kanal kommen und denselben group_key haben. Ohne group_key vergleicht Honk Titel und Nachricht exakt, sodass nur identische Ereignisse zusammenkommen.

Eine Episode ist ein Problem innerhalb einer Gruppe, vom ersten Ereignis bis zu seinem Ende. Sie endet auf eine von zwei Arten: Die Quelle gibt für denselben group_key Entwarnung, oder eine Weile kommt nichts mehr (standardmäßig 24 Stunden), und die Episode wird inaktiv. Inaktiv heißt nicht behoben: Das nächste Ereignis eröffnet eine neue Episode und pusht wieder.

Als erledigt markieren ist nur deine eigene Markierung, dass du dich um eine Episode gekümmert hast. Behoben ist das Problem damit nicht, und eine neue Episode braucht wieder deine Aufmerksamkeit.

Einen Gruppenschlüssel wählen

db/backup
ein Job: Jeder Fehlschlag des nächtlichen Backups landet in einer Gruppe
requests/4812
eine Kundenanfrage pro Gruppe, damit zwei Kunden nie in einem Push landen
disk/app-01/var
eine Festplatte auf einem Server
ci/acme/api/main
ein Branch eines Repositorys in der CI

Was gepusht wird

Das entscheidet der Server, für jede Person, die dem Projekt folgt, und zwar jedes Mal nach denselben Regeln. Die KI auf dem iPhone kann eine Mitteilung umformulieren, aber daran, was gepusht wird, ändert sie nie etwas.

Das erste Ereignis einer Episode Sofort gepusht.
Eine lautere Stufe als beim letzten Push Sofort gepusht, auch während der Wartezeit. Stummschaltungen gelten weiterhin.
Eine Entwarnung Sofort gepusht, mit der Uhrzeit, die die Quelle gemeldet hat.
Weitere gleiche Ereignisse Höchstens ein Update pro Wartezeit (standardmäßig 5 Minuten, einstellbar von 1 bis 120), mit dem aktuellen Zählerstand.
Unter deiner Push-Schwelle Wird für die Zusammenfassung gesammelt, die standardmäßig alle 15 Minuten kommt. Eine leere Zusammenfassung wird nie gesendet.
Während deiner Ruhezeiten Zurückgehalten, danach kommt eine einzige Zusammenfassung. Durch kommen nur dringende Ereignisse von einem Schlüssel, der sie senden darf.
Stummgeschaltet, oder eine Regel sagt „nur Posteingang“ Kein Push. Das Ereignis ist trotzdem im Posteingang und bleibt ungelesen.

Langes Hupen und Dauerhupen haben immer mindestens die Priorität Hoch. Für die Priorität Dringend muss beim Ingest-Schlüssel „Priorität ‚dringend‘ erlauben“ aktiviert sein.

Eine Nacht mit Ruhezeiten

Ruhezeiten gelten pro Person und pro Projekt, in deiner eigenen Zeitzone, und sie berücksichtigen die Zeitumstellung. So sieht eine Nacht mit Ruhezeiten von 22:00 bis 07:00 aus:

  1. Die Ruhezeiten beginnen.
  2. Zweimal Leichtes Hupen von einem Backup-Job. Beides geht in die Zusammenfassung.
  3. Ein Langes Hupen von der Billing-API. Es wartet bis zum Morgen.
  4. Ein dringendes Dauerhupen von einem Schlüssel, der dringende Ereignisse senden darf. Es kommt durch, und auf dem Sperrbildschirm startet eine Live-Aktivität.
  5. Die Quelle gibt Entwarnung. Die Live-Aktivität zeigt „Behoben“.
  6. Die Ruhezeiten enden. Ein einziger Push zeigt, was zurückgehalten wurde.

Um durchzukommen, braucht ein Ereignis drei Dinge: Es wird mit der Priorität urgent gesendet, beim Ingest-Schlüssel ist „Priorität ‚dringend‘ erlauben“ aktiviert, und in deinen Ruhezeiten ist „Dringende Nachrichten durchlassen“ aktiviert.

Zusammenfassungen und Tagesüberblick

Routineereignisse unter deiner Push-Schwelle sammelt Honk in einer Zusammenfassung: standardmäßig ein Push alle 15 Minuten, pro Projekt und Person einstellbar von 5 Minuten bis 24 Stunden. Leere Zusammenfassungen werden nie gesendet.

Der Tagesüberblick ist ein ruhiger Push am Tag, zur Uhrzeit deiner Wahl, standardmäßig um 8:00 Uhr. Ein typischer lautet „2 offene Vorfälle · 5 neue Kundenanfragen · 120 Nachrichten seit gestern“. Er entfällt an Tagen, an denen nichts angekommen ist, und wartet, bis deine Ruhezeiten enden.

Regeln und Stummschaltung

Die Regeln eines Projekts laufen der Reihe nach über jedes Ereignis. Eine Regel kann auf Titel, Nachricht, Quelle, Umgebung, Kanal, Schweregrad, Priorität, Ereignistyp, Gruppenschlüssel, Kategorie oder ein Metadatenfeld prüfen. Trifft sie zu, kann sie das Ereignis in die Zusammenfassung schicken, nur im Posteingang ablegen, ihm eine Kategorie geben oder seine Priorität anheben.

Stummschaltungen betreffen nur dich. Schalte eine Gruppe über ihre Mitteilung für eine Stunde stumm, schalte ein ganzes Projekt stumm, oder stoppe mit Alles stummschalten im Kontrollzentrum eine Stunde lang alle Pushes aus dem Workspace. Stummgeschaltete Ereignisse kommen trotzdem an und bleiben ungelesen.

Workspaces und Projekte

Ein Workspace legt fest, wer dabei ist und wie viel ihr nutzen dürft. Ein Projekt beschreibt, woher die Ereignisse kommen.

Zu einem Workspace gehören die Mitglieder mit ihren Rollen (Inhaber, Admin oder Mitglied) und ein Tarif. Die Limits des Tarifs gelten pro Workspace.

Ein Projekt ist eine App, ein Server oder ein Skript. Jedes Projekt hat eigene Ingest-Schlüssel, Regeln und eine eigene Aufbewahrung (bis zum Limit des Tarifs) sowie eigene Einstellungen für Zusammenfassung und Wartezeit.

  • Alle starten mit einem persönlichen Workspace im Free-Tarif.
  • Ein Team legt einen gemeinsamen Workspace an und lädt Leute ein.
  • Inhaber und Admins sehen jedes Projekt. Mitglieder sehen die Projekte, auf die sie Zugriff haben.
  • Ruhezeiten, Stummschaltungen und Push-Einstellungen gelten pro Person und pro Projekt. Am Handy von jemand anderem ändern sie also nie etwas.

Wer Sentry kennt, kennt das Modell schon: Ein Workspace ist eine Organisation, ein Projekt ist ein Projekt, und ein Ingest-Schlüssel ist ein DSN.

Ein Beispiel-Workspace
Acme Labs Team-Tarif 3 Mitglieder: ein Inhaber, ein Admin, ein Mitglied
  • Billing API 2 Ingest-Schlüssel · 4 Regeln · 30 Tage
  • Zuhause 1 Ingest-Schlüssel · Ruhezeiten 22:00 bis 07:00

Was Honk nicht ist

  • Kein Monitoring. Honk empfängt Ereignisse, es prüft deine Dienste nicht. Fällt ein Server still aus, kommt nichts an. Lass deshalb auch einen Uptime-Check an Honk melden.
  • Kein Tool für Rufbereitschaft. Es gibt keine Dienstpläne und keine Eskalationsstufen, und Honk schickt nie eine SMS und ruft dich nie an.
  • Kein Archiv. Nachrichten werden je nach Tarif nach 3, 14 oder 30 Tagen gelöscht.