Filter-Alarme

Ein Filter-Alarm überwacht eine ganze Ticket-Menge statt eines einzelnen Tickets. Den Bereich definiert eine JQL-Abfrage oder ein gespeicherter Jira-Filter: „jedes Ticket im Projekt X“, „alle kritischen Bugs“, „jeder Request in meiner Queue“.

Filter-Alarme entstehen auf der HeadsUp-Übersichtsseite: Apps → HeadsUp → + Neuer Filter-Alarm.

Dialog „Neuer Filter-Alarm“ mit gewähltem Filter und gefülltem JQL-Feld

Einen Filter-Alarm anlegen

Bereich wählen. Am einfachsten über das Dropdown „Gespeicherten Filter übernehmen (optional)“: Es listet die eigenen Jira-Filter und kopiert die JQL, die editierbar bleibt. Direkte JQL-Eingabe funktioniert ebenfalls; sie wird beim Speichern validiert.
Auslöser wählen:
- Neues Ticket erscheint im Filter, zum Beispiel jeder neue Bug im Projekt X
- Status-Änderung (beliebig oder Zielstatus), neuer Kommentar, Prioritäts-Änderung, Zuweisungs-Änderung
- KI erkennt …, eine Bedingung in eigenen Worten über alle Tickets des Filters, siehe KI-Erkennung
- SLA wird bald verletzt, siehe unten
Optional einen Namen vergeben. Der Name erscheint im Mail-Betreff in eckigen Klammern, damit die Quelle einer Benachrichtigung auf einen Blick klar ist.

Filter-Alarme bleiben dauerhaft aktiv, bis sie gelöscht werden.

Ablaufdatum

Filter-Alarme laufen immer dauerhaft und können deshalb ein Ablaufdatum bekommen. Das Feld Läuft aus bietet Kein Ablaufdatum, In 2 Wochen, In 1 Monat, In 3 Monaten, In 6 Monaten oder ein bestimmtes Datum. Voreingestellt ist kein Ablaufdatum.

Besonders wichtig ist das bei der KI-Erkennung: ein vergessener Alarm verbraucht weiter die gemeinsamen KI-Credits der Instanz. Ein Ablaufdatum beendet das, ohne dass jemand daran denken muss.

Sieben Tage vor dem Termin kommt ein Hinweis, sodass sich der Alarm verlängern lässt. Ein abgelaufener Alarm wird stillgelegt und nicht gelöscht, ein Klick weckt ihn wieder.

SLA-Frühwarnung (Advanced-Edition)

Für Jira Service Management kann ein Filter-Alarm warnen, bevor ein SLA verletzt wird: Auslöser „SLA wird bald verletzt“ wählen und eine Schwelle festlegen (1, 2, 4, 8 oder 24 Stunden). HeadsUp prüft offene Requests stündlich und meldet jeden Request genau einmal pro Alarm, damit aus einer nahenden Verletzung kein stündlicher Spam wird. Je Lauf prüft ein Alarm die ersten 50 offenen Vorgänge seines Filters. Eine Queue mit mehr offenen Vorgängen teilt man besser auf mehrere Alarme auf, etwa nach Projekt oder Priorität.

Dieser Auslöser gehört zur Advanced-Edition. In der Standard-Edition erscheint er nicht in der Auslöser-Liste.

Zwei Fälle bleiben absichtlich still. Ein angehaltenes SLA warnt nicht, denn während ein Request beim Kunden liegt, läuft die Uhr nicht, und nach dem Fortsetzen kommt die Warnung noch. Eine bereits eingetretene Verletzung warnt ebenfalls nicht, denn eine Frühwarnung im Nachhinein ist keine.

Auslöser-Dropdown mit gewähltem „SLA wird bald verletzt“ und geöffneter Schwellen-Auswahl

Das Protokoll eines Filter-Alarms

Auch unter jedem Filter-Alarm auf der Übersichtsseite steht Protokoll anzeigen. Aufgeklappt zeigt es, was der Alarm getan hat: ausgelöst und zugestellt, von der KI bewertet, oder auch, dass Jira die JQL abgelehnt hat oder die SLA-Daten nicht lesbar waren. Geladen wird erst beim Aufklappen. Die Liste der möglichen Einträge steht unter Benachrichtigungen und Inbox.

Ändern und Löschen

Ein Filter-Alarm lässt sich nicht bearbeiten. Auf der Übersichtsseite steht bei ihm nur Löschen, und der Server weist eine Änderung ebenfalls ab. Wer JQL, Auslöser oder Namen ändern will, löscht den Alarm und legt ihn neu an; die JQL eines gespeicherten Filters ist ohnehin ein Schnappschuss. Bei Ticket-Erinnerungen ist das anders, sie lassen sich im Panel am Ticket wie auf der Übersichtsseite bearbeiten.

Genauigkeit

Filter-Alarme auf Ereignisse (Status, Kommentar, Priorität, Zuweisung, neues Ticket) reagieren innerhalb von Sekunden. Die SLA-Prüfung läuft stündlich; eine Warnung kann bis zu etwa einer Stunde nach Unterschreiten der Schwelle eintreffen.