Redmine SLA
SupportVier Stunden SLA sind nicht vier Stunden. Reaktion und Lösung werden in Arbeitszeit gemessen — Ihre Kalender, Ihre Feiertage, Ihre Pausenregeln — mit Warnung, kritischem Schwellwert und Verletzungserkennung.
Mehrere Server: $399
- Redmine
- 4, 5, 6 und 7
- Ziele
- 4 unabhängige Uhren
- Datenbanken
- PostgreSQL, MySQL, MariaDB, SQLite
- Berichte
- 4, mit CSV-Export
- Zusätzliche Gems
- Keine
- Geänderte Core-Dateien
- Keine
Arbeitszeiten, richtig gerechnet
Wochenpläne mit geteilten Schichten, Zeitzone je Kalender, feste und wiederkehrende Feiertage sowie Sonderarbeitstage. Wanduhrzeit über die Zeitumstellung hinweg, sodass 09:00–18:00 auch 09:00–18:00 bleibt.
Vier unabhängige Uhren
Erste Reaktion, Bestätigung, Lösung und Abschluss — jede mit eigenem Ziel, eigenem Zustand und eigenem Pausenverhalten. Konfigurieren Sie nur die, die Sie brauchen.
Warten auf den Kunden
Regeln je Status entscheiden, welche Uhren stehen bleiben. „Warten auf Kunde“ kann die Lösung einfrieren, während die erste Reaktion weiterläuft — denn die schulden immer noch Sie.
Bedingungen in Klartext
Treffer nach Projekt, Tracker, Status, Kategorie, Zuständigem, Gruppe, Kunde oder beliebigem Custom-Field — über echte Namen, nie über Datensatz-IDs.
Warnung, kritisch, Verletzung
Schwellwerte lösen vor der Frist aus, nicht danach. Der Versand läuft über Redmines eigenen Mailer, und ein eindeutiger Index verhindert doppelte Benachrichtigungen.
Belastbare Auswertungen
Erfüllung je Ziel, Verteilungen von Reaktions- und Lösungszeiten mit Median und Ausreißern sowie eine Verletzungstabelle mit Fälligkeit, tatsächlichem Zeitpunkt und Überschreitung.
Ihre Uhr bleibt stehen, wenn Ihr Team Feierabend macht
Wer einfach zwei Zeitstempel voneinander abzieht, wird für Wochenenden bestraft. Redmine SLA geht Ihren Geschäftskalender durch und zählt nur die Minuten, in denen Sie geöffnet haben. Ein Vier-Stunden-Ziel, das am späten Freitag gemeldet wird, ist also am Montag fällig, nicht noch in derselben Nacht.
| Ticket gemeldet | Gezählte Arbeitszeit | Fällig | Reale Zeit |
|---|---|---|---|
| Dienstag 09:30 | 4h, ohne Unterbrechung | Dienstag 13:30 | 4 Stunden |
| Freitag 17:00 | 1h am Freitag, 3h am Montag | Montag 12:00 | 67 Stunden |
| Freitag 17:00, Montag ist Feiertag | 1h am Freitag, 3h am Dienstag | Dienstag 12:00 | 91 Stunden |
| Jederzeit, in einem 24×7-Kalender | 4h verstrichen | Vier Stunden später | 4 Stunden |
Kalender unterstützen geteilte Schichten, eine eigene Zeitzone, einmalige und wiederkehrende Feiertage sowie besondere Arbeitstage.
Vier Uhren, jede mit eigenen Regeln
Legen Sie nur die Ziele fest, die Sie tatsächlich zusagen. Jedes startet, pausiert und stoppt bei seinem eigenen Ereignis. So kann „Warten auf den Kunden“ die Lösung einfrieren, während die erste Reaktion weiterläuft.
Erste Reaktion: Jemand hat geantwortet
Stoppt beim ersten öffentlichen Kommentar von jemand anderem als dem Autor. Was als Antwort zählt, wird je Richtlinie festgelegt.
Übernahme: Jemand ist zuständig
Stoppt, sobald das Ticket zugewiesen wird oder einen von Ihnen gewählten Status erreicht.
Lösung: Das Problem ist behoben
Stoppt, sobald das Ticket einen geschlossenen Status oder einen der von Ihnen gewählten Lösungsstatus erreicht.
Abschluss: Das Ticket ist erledigt
Ein eigenes Ziel für das endgültige Schließen, für Teams, die erst lösen und später mit dem Kunden bestätigen.
Es sieht aus wie Redmine, weil es Redmine ist
Kein iframe, keine separate App, kein zweiter Login. Das sind echte Ansichten des Plugins unter Redmine 7.0. Sie zeigen ein Demoprojekt mit Tickets in jedem SLA-Zustand.
Bearbeiter: das SLA-Panel in jedem Ticket
Eine Zeile je Ziel, mit Zustand, verbleibender Zeit, verbrauchtem Anteil des Ziels und der genauen Fälligkeit.
Teamleiter: die Warteschlange, sortiert nach dem, was als Nächstes schiefgeht
Nach Status, Zustand, Richtlinie oder Verletzung filtern, nach Fälligkeit sortieren, als CSV exportieren. Dieselben Felder gibt es als Filter und Spalten in Redmines eigener Ticketliste.
Manager: Berichte, die Sie einem Kunden vorlegen können
Erfüllung, Reaktionszeit, Lösungszeit und Verletzungen, gefiltert nach Zeitraum, Richtlinie, Tracker und Priorität. Jeder Bericht lässt sich als CSV exportieren.
Admins: Richtlinien in klaren Worten
„Wenn die Priorität des Tickets eine von Dringend, Sofort ist.“ Bedingungen verwenden echte Namen aus Auswahllisten, keine Datensatz-IDs. Als Dauer sind 30, 4h oder 1d 4h möglich.
Betrieb: ein Ort, an dem Sie sehen, dass alles läuft
Alles, worüber ein Service-Desk tatsächlich streitet
Gestritten wird selten darüber, ob ein Ticket zu spät war. Es geht darum, welche Stunden gezählt haben, wann die Uhr hätte stoppen müssen und welches Ziel damals galt.
Arbeitszeiten, richtig gemacht
Wochenpläne mit geteilten Schichten, Zeitzonen je Kalender, festen und wiederkehrenden Feiertagen und besonderen Arbeitstagen. 09:00 bleibt 09:00, auch bei der Umstellung auf Sommer- oder Winterzeit.
Warten auf den Kunden
Pausenregeln je Status, global oder je Richtlinie. Gutgeschrieben wird nur Arbeitszeit, eine Pause über das Wochenende kostet also nichts.
Warnung, kritisch, Verletzung
Schwellwerte lösen vor Fristablauf aus. Jede Benachrichtigung wird genau einmal über Redmines eigenen Mailer verschickt, mit Vorlagen, die Sie je Ereignis und Sprache bearbeiten können.
Die richtige Richtlinie für jedes Ticket
Abgleich nach Projekt und Unterprojekten, Tracker, Priorität, Status, Kategorie, Autor, Bearbeiter, Gruppe oder einem beliebigen benutzerdefinierten Feld. Passen mehrere Richtlinien, gewinnt die mit der niedrigeren Position.
Direkt in der Ticketliste
SLA-Richtlinie, Status, Zustand, Verletzung, Fälligkeit und Restzeit als Filter und Spalten in Redmines Ticketliste: sortierbar, gruppierbar und exportierbar.
Änderungen schreiben die Vergangenheit nicht um
Jede SLA behält einen Snapshot der Richtlinie, mit der sie gestartet ist. Wenn Sie im nächsten Quartal ein Ziel ändern, bleiben die Zahlen des letzten Quartals unberührt. Eine Neuberechnung ist eine bewusste Admin-Aktion.
Was mit einem Ticket geschieht
Ein kritischer Fehler, gemeldet an einem Freitagnachmittag, in einem Kalender von Montag bis Freitag 09:00 bis 18:00, mit einem Ziel von 30 Minuten für die erste Reaktion und einem Lösungsziel von vier Stunden.
| Wann | Ereignis | Was das Plugin tut |
|---|---|---|
| Fr 15:00 | Gemeldet | Die erste passende Richtlinie wird zugewiesen und ihre Uhren starten. Heute bleiben noch drei Arbeitsstunden, eine wandert also auf den Montag. |
| Fr 15:20 | Erste Antwort | Ein öffentlicher Kommentar eines Bearbeiters stoppt die Uhr für die erste Reaktion bei 20 Minuten, innerhalb des 30-Minuten-Ziels. |
| Fr 16:00 | Wartend | Die Lösung pausiert. Antwortet der Kunde am Montag, verschiebt sich die Fälligkeit um genau die verlorene Arbeitszeit. |
| Montag | Warnung bei 75 % | Die Warn-E-Mail geht raus, solange noch Zeit zum Handeln ist. |
| Montag | Gelöst | Die verbrauchte Zeit und die Zielerreichung werden festgehalten und ändern sich danach nie wieder. |
| Verbraucht | Zustand |
|---|---|
| Unter 75 % | Im Zeitplan |
| 75% | Gefährdet |
| 90% | Kritisch |
| 100% | Verletzt |
| Angehalten | Pausiert |
| Ziel erreicht | Abgeschlossen |
JSON für jede Ansicht
Eine lesende JSON-API deckt alles ab, was die Ansichten zeigen. Sie authentifiziert sich mit einem normalen Redmine-API-Schlüssel und folgt denselben Berechtigungen wie die Seiten.
| Methode | Endpunkt | Liefert |
|---|---|---|
| GET | /sla/issues/:id.json | Die SLA eines Tickets |
| GET | /sla/issues.json | SLA-Tickets, filterbar |
| GET | /projects/:id/sla/issues.json | SLA-Tickets eines Projekts |
| GET | /sla/timeline/:id.json | Zeitleiste eines Tickets |
| GET | /sla/dashboard.json | Dashboard-Zähler und Erfüllung |
| GET | /sla/reports/:report.json | Jeden der vier Berichte |
| GET | /sla/policies.json | Richtlinien und ihre Ziele |
| GET | /sla/calendars.json | Kalender und Arbeitszeiten |
Die SLA eines Tickets auslesen
Senden Sie Ihren Schlüssel im Header X-Redmine-API-Key. Die Antwort enthält die Richtlinie, den Kalender, den Gesamtzustand und einen Eintrag je Ziel mit Zustand, Fälligkeit und verbrauchter Zeit. So bringen Sie SLA-Countdowns auf ein Wallboard oder übernehmen Erfüllungszahlen in Ihr eigenes Reporting.
Sechs Berechtigungen, je Rolle vergeben
SLA ist ein normales Redmine-Projektmodul. Aktivieren Sie es in den Projekten, die Sie messen, und geben Sie jeder Rolle nur das, was sie braucht. Redmine-Administratoren haben die beiden globalen Berechtigungen immer.
| Berechtigung | Geltungsbereich | Was sie erlaubt |
|---|---|---|
| view_sla | Projekt | Das SLA-Panel in Tickets, die Liste der SLA-Tickets und die Zeitleiste ansehen |
| view_sla_dashboard | Projekt | Das SLA-Dashboard ansehen |
| view_sla_reports | Projekt | Die SLA-Berichte ansehen und exportieren |
| manage_sla | Projekt | Die SLA-Einstellungen des Projekts bearbeiten und die SLA eines Tickets neu berechnen |
| manage_sla_policies | Global | Richtlinien und Pausenregeln anlegen und bearbeiten |
| manage_sla_calendars | Global | Kalender und Feiertage anlegen und bearbeiten |
Läuft dort, wo Ihr Redmine bereits läuft
| Umgebung | Status | Hinweise |
|---|---|---|
| Redmine 7.x | Unterstützt | Getestet unter Redmine 7.0 mit Rails 8.1 und Ruby 3.4.2. Die Screenshots auf dieser Seite stammen aus 7.0. |
| Redmine 6.x | Unterstützt | |
| Redmine 5.x | Unterstützt | Benötigt nach der Migration den Plugin-Assets-Task |
| Redmine 4.x | Unterstützt | 4.0 ist die Mindestversion, die das Plugin angibt |
| Datenbanken | Unterstützt | PostgreSQL, MySQL, MariaDB und SQLite, ohne datenbankspezifisches SQL |
| Zusätzliche Gems | Keine | Kein Redis, kein Sidekiq. Ein cron-Eintrag oder systemd-Timer führt die Hintergrundprüfung aus. |
| Redmine-Core | Unberührt | Keine Core-Datei wird bearbeitet, Redmine-Upgrades bleiben also unberührt |
In drei Schritten installiert
Erfordert Shell-Zugriff und die Möglichkeit, Rake-Tasks auszuführen. Sichern Sie vor jeder Plugin-Installation Ihre Daten.
cd /path/to/redmine # the package arrives by email, or from your download link unzip redmine_sla-1.0.0.zip -d plugins/
RAILS_ENV=production bundle exec rake redmine:plugins:migrate # Redmine 4 and 5 only (Redmine 6+ serves plugin assets directly) RAILS_ENV=production bundle exec rake redmine:plugins:assets touch tmp/restart.txt # or systemctl restart redmine
# every five minutes: evaluate timers that are due, safe to run repeatedly */5 * * * * cd /path/to/redmine && RAILS_ENV=production bundle exec rake redmine_sla:process >> log/sla.log 2>&1
# Administration → SLA → create the default business calendars, then follow the checklist # Administration → SLA → Policies → write one policy: targets, calendar, conditions # Project → Settings → Modules → tick SLA for each project you measure # Administration → Roles and permissions → grant the SLA permissions
Verändert das Plugin Dateien des Redmine-Core?
Was passiert mit bestehenden SLAs, wenn ich eine Richtlinie bearbeite?
Braucht es Redis, Sidekiq oder zusätzliche Gems?
Können verschiedene Kunden oder Projekte unterschiedliche SLAs haben?
Was ist mit Tickets, die schon vor der Installation existierten?
Ist die Deinstallation sicher?
Sind die Screenshots echt?
Preise
Ein Server
Eine Redmine-Instanz · unbegrenzt viele Benutzer · 12 Monate Updates.
Mehrere Server
Unbegrenzt viele Redmine-Server · unbegrenzt viele Benutzer · 12 Monate Updates.