Redmine SLA

Support

5.0 (0)·New installazioni

Un SLA di quattro ore non dura quattro ore. Risposta e risoluzione misurate in tempo lavorativo: i tuoi calendari, le tue festività, le tue regole di pausa, con avvisi, soglia critica e rilevamento delle violazioni.

$199 / un server

Guida utente

Più server: $399

Rimborso entro 5 giorni lavorativi12 mesi di aggiornamentiSorgenti incluse

Il cruscotto SLA di un progetto Redmine: un anello di conformità al 75 % con prima risposta all’80 % e risoluzione al 66,7 %, risposta media di 35 minuti e risoluzione media di 12 ore e 40 minuti, contatori per 10 richieste SLA di cui 6 in corso, 2 a rischio, 3 violate, 1 in pausa e 2 completate, una barra della salute a colori, tabelle delle richieste a rischio e violate con le scadenze, e la conformità per politica SLA. — Progetto › SLA Conformità per obiettivo, contatori in tempo reale e ogni richiesta a rischio o violata con la sua scadenza.

Redmine: 4, 5, 6 e 7
Obiettivi: 4 orologi indipendenti
Database: PostgreSQL, MySQL, MariaDB, SQLite
Report: 4, con esportazione CSV
Gem aggiuntive: Nessuna
File del core modificati: Nessuna

Working hours, properly

Weekly schedules with split shifts, per-calendar time zones, fixed and recurring holidays and special working days. Wall-clock across DST, so 09:00–18:00 stays 09:00–18:00.

Four independent clocks

First response, acknowledgement, resolution and closure — each with its own target, state and pause behaviour. Configure only the ones you use.

Waiting on the customer

Per-status rules decide which clocks stop. “Waiting for customer” can freeze resolution while first response keeps running — because that one is still on you.

Conditions in plain words

Match on project, tracker, status, category, assignee, group, customer or any custom field — by real names, never record IDs.

Warning, critical, breach

Thresholds fire before the deadline, not after it. Mail goes through Redmine’s own mailer, and a unique-index claim means no alert is ever sent twice.

Compliance you can defend

Compliance by target, response and resolution distributions with median and outliers, and a breach table with due date, actual date and overrun.

Il tuo orologio si ferma quando la squadra va a casa

Sottrarre due date ti penalizza per i fine settimana. Redmine SLA percorre il tuo calendario lavorativo e conta solo i minuti in cui sei aperto: un obiettivo di quattro ore aperto il venerdì sul tardi scade lunedì, non la sera stessa.

Un obiettivo di risoluzione di quattro ore su un calendario dal lunedì al venerdì, dalle 09:00 alle 18:00
Richiesta aperta	Tempo lavorativo contato	Scadenza	Tempo reale
Martedì 09:30	4h, senza interruzioni	Martedì 13:30	4 ore
Venerdì 17:00	1h venerdì, 3h lunedì	Lunedì 12:00	67 ore
Venerdì 17:00, lunedì festivo	1h venerdì, 3h martedì	Martedì 12:00	91 ore
In qualsiasi momento, su un calendario 24×7	4h trascorse	Quattro ore dopo	4 ore

I calendari supportano turni spezzati, un proprio fuso orario, festività singole e ricorrenti e giornate lavorative straordinarie.

Quattro orologi, ognuno con le sue regole

Imposta solo gli obiettivi che prometti davvero. Ognuno parte, va in pausa e si ferma su un proprio evento: così “in attesa del cliente” può congelare la risoluzione mentre la prima risposta continua a correre.

Prima risposta: qualcuno ha risposto

Si ferma al primo commento pubblico di chiunque non sia l’autore. Cosa conta come risposta si definisce per politica.

Presa in carico: qualcuno se ne occupa

Si ferma quando la richiesta viene assegnata o raggiunge uno stato scelto da te.

Risoluzione: il problema è risolto

Si ferma quando la richiesta raggiunge uno stato chiuso o uno degli stati di risoluzione scelti da te.

Chiusura: il ticket è concluso

Un obiettivo separato per la chiusura definitiva, per le squadre che prima risolvono e poi confermano con il cliente.

Sembra Redmine, perché è Redmine

Nessun iframe, nessuna app separata, nessun secondo login. Queste sono schermate reali del plugin su Redmine 7.0 e mostrano un progetto demo con richieste in ogni stato SLA.

Operatori: il pannello SLA su ogni richiesta

Una riga per obiettivo, con lo stato, il tempo rimanente, la quota di obiettivo consumata e la scadenza esatta.

Un bug di Redmine, Checkout page intermittently times out, con un pannello SLA sotto gli attributi. Il pannello è contrassegnato A rischio e mostra la politica SLA demo - Critical su un calendario 24x7 in UTC. La prima risposta è A rischio, con pochi minuti rimanenti e un anello di avanzamento oltre l’80 %. La risoluzione è In salute, con più di tre ore rimanenti. Sotto ci sono i link alla cronologia SLA e al ricalcolo. — Pagina della richiesta La prima risposta è a rischio e mancano pochi minuti, mentre la risoluzione è ancora in salute. Il conto alla rovescia si aggiorna in tempo reale e il pannello indica la politica, il calendario e il fuso orario su cui viene misurato.

Il pannello SLA di una richiesta in pausa: prima risposta completata in 5 minuti su un obiettivo di 30 minuti, e risoluzione in pausa al 50 % con 2 ore consumate su 4. — In pausa L’operatore ha risposto in 5 minuti, poi la richiesta è passata a uno stato di attesa. La risoluzione resta congelata a 2h su 4h finché il cliente non risponde.

La cronologia SLA dello stesso bug: timer avviati per prima risposta e risoluzione, SLA avviato, timer di prima risposta completato, SLA assegnato alla politica Critical e timer di risoluzione in pausa, ciascuno con data e ora e l’utente che lo ha provocato. — Cronologia SLA Ogni avvio, completamento, pausa e violazione in ordine, con chi l’ha provocato. È il registro che mostri quando un cliente contesta un numero.

Team leader: la coda, ordinata per ciò che sta per andare storto

Filtra per stato, salute, politica o violazione, ordina per scadenza, esporta in CSV. Gli stessi campi sono filtri e colonne nella lista delle richieste di Redmine.

La lista delle richieste SLA con filtri per stato SLA, salute SLA, politica e violazione. Sono elencate dieci richieste con progetto, politica SLA, stato, un badge colorato della salute (in pausa, completato, violato, critico, a rischio o in salute), il risultato o il tempo rimanente per prima risposta e risoluzione, e la scadenza SLA. — Richieste SLA Dieci richieste in tutti gli stati di salute: in pausa, completato, violato, critico, a rischio e in salute, ognuna con il tempo rimanente o lo sforamento per entrambi gli obiettivi.

Manager: report da mettere davanti a un cliente

Conformità, tempo di risposta, tempo di risoluzione e violazioni, filtrati per periodo, politica, tracker e priorità. Ogni report si esporta in CSV.

La pagina dei report SLA sulla scheda conformità, con scorciatoie di periodo da 7 giorni a sempre, filtri per politica SLA, tracker e priorità, e un riepilogo di conformità del 75 % con prima risposta all’80 % e risoluzione al 66,7 %. — Conformità Obiettivi rispettati rispetto a quelli misurati, suddivisi tra prima risposta e risoluzione.

Il report sul tempo di risposta: mediana 10 minuti, media 35 minuti, minimo 5 minuti, massimo 2 ore su 5 risposte misurate, e un istogramma di distribuzione con fasce da 15 minuti a oltre 3 giorni. — Tempo di risposta Mediana, media, più rapida e più lenta, più una distribuzione che mostra dove si trovano i valori anomali.

Il report delle violazioni, che elenca quattro violazioni nel periodo con richiesta, progetto, politica SLA, priorità, assegnatario, tipo di violazione (prima risposta o risoluzione), scadenza SLA, data effettiva e durata della violazione. — Violazioni Quale obiettivo è stato mancato su quale richiesta, quando scadeva, quando è stato effettivamente raggiunto e di quanto ha sforato.

Amministratori: politiche scritte in parole semplici

“Quando la Priorità della richiesta è una tra Urgente, Immediata.” Le condizioni usano nomi reali scelti da elenchi, non ID di record. Le durate accettano 30, 4h o 1d 4h.

Il modulo della politica SLA: nome, descrizione, attiva, predefinita e posizione, poi gli obiettivi di prima risposta, presa in carico, risoluzione e chiusura, un calendario lavorativo e un fuso orario, e una tabella di condizioni in cui Priorità è una tra Urgente e Immediata. — Obiettivi e condizioni I quattro obiettivi, il calendario su cui vengono misurati e le condizioni che decidono a quali richieste si applica la politica.

La sezione eventi del modulo della politica: lo SLA parte alla creazione della richiesta, la prima risposta si ferma al primo commento pubblico e ignora gli aggiornamenti dell’autore della richiesta, la presa in carico si ferma quando la richiesta viene assegnata, e risoluzione e chiusura si fermano quando la richiesta raggiunge uno stato chiuso o uno degli stati selezionati. — Eventi Scegli cosa avvia ogni orologio e cosa lo ferma.

Le soglie nel modulo della politica fissano l’avviso al 75 % e il livello critico al 90 % con notifiche attive, sopra una tabella di regole di pausa in cui uno stato mette in pausa Risoluzione e Chiusura ma non Prima risposta o Presa in carico. — Soglie e regole di pausa Avvisa al 75 %, passa a critico al 90 % e spunta quali obiettivi vengono congelati da ogni stato.

L’orario di lavoro di un calendario lavorativo: dalle 09:00 alle 18:00 dal lunedì al venerdì, fine settimana vuoti, un secondo periodo facoltativo al giorno per i turni spezzati e una scorciatoia per applicare dal lunedì al venerdì 09:00-18:00. — Calendario lavorativo Orario di lavoro per giorno della settimana, un secondo periodo per i turni spezzati, un fuso orario e le festività, oppure semplicemente 24×7.

La scheda SLA nelle impostazioni del progetto Redmine: SLA attivo, eredita dal progetto padre, calendario lavorativo, politica SLA e fuso orario predefiniti, più caselle che limitano quali politiche SLA il progetto può usare. — Impostazioni del progetto Attiva lo SLA per progetto, eredita dal progetto padre, sostituisci il calendario o limita le politiche applicabili.

Operations: un unico posto per vedere che tutto funziona

La pagina di amministrazione SLA: una checklist di configurazione per calendari lavorativi, politiche, progetti attivi, regole di pausa globali ed elaborazione in background con l’ora dell’ultima esecuzione, una panoramica con contatori e conformità al 75 %, e link a politiche, calendari, festività, regole di pausa, modelli email, impostazioni, report, richieste SLA e registro di audit. — Amministrazione › SLA Una checklist di configurazione che ti dice cosa manca, quando è stato eseguito l’ultima volta il task in background, e una panoramica in tempo reale.

Il registro di audit SLA: una tabella filtrabile che elenca quando ogni SLA è stato assegnato o ricalcolato, da quale utente, su quale oggetto, con dettagli come il nome della politica e l’ID della richiesta. — Registro di audit Chi ha assegnato, modificato o ricalcolato quale SLA, e quando.

Tutto ciò su cui un service desk discute davvero

Raramente si discute se un ticket fosse in ritardo. Si discute di quali ore contavano, di quando l’orologio avrebbe dovuto fermarsi e di quale fosse l’obiettivo in quel momento.

Orari di lavoro, fatti come si deve

Orari settimanali con turni spezzati, fusi orari per calendario, festività fisse e ricorrenti e giornate lavorative straordinarie. Le 09:00 restano le 09:00 anche al cambio dell’ora legale.

In attesa del cliente

Regole di pausa per stato, globali o per politica. Viene restituito solo il tempo lavorativo, quindi una pausa nel fine settimana non costa nulla.

Avviso, critico, violazione

Le soglie scattano prima della scadenza. Ogni notifica viene inviata una sola volta tramite il mailer di Redmine, con modelli modificabili per evento e lingua.

La politica giusta per ogni richiesta

Abbina per progetto e sottoprogetti, tracker, priorità, stato, categoria, autore, assegnatario, gruppo o qualsiasi campo personalizzato. Quando più politiche corrispondono, vince quella con la posizione più bassa.

Dentro la lista delle richieste

Politica SLA, stato, salute, violazione, scadenza e tempo rimanente come filtri e colonne nella lista delle richieste di Redmine: ordinabili, raggruppabili ed esportabili.

Le modifiche non riscrivono la storia

Ogni SLA conserva un’istantanea della politica con cui è partito. Cambiare un obiettivo il prossimo trimestre non tocca i numeri del trimestre scorso. Il ricalcolo è un’azione deliberata dell’amministratore.

Cosa succede a una richiesta

Un bug critico aperto un venerdì pomeriggio, su un calendario dal lunedì al venerdì 09:00-18:00, con un obiettivo di prima risposta di 30 minuti e un obiettivo di risoluzione di quattro ore.

Quando	Evento	Cosa fa il plugin
Ven 15:00	Aperta	La prima politica corrispondente viene associata e i suoi orologi partono. Oggi restano tre ore lavorative, quindi una slitta a lunedì.
Ven 15:20	Prima risposta	Un commento pubblico di un operatore ferma l’orologio della prima risposta a 20 minuti, entro l’obiettivo di 30 minuti.
Ven 16:00	In attesa	La risoluzione va in pausa. Quando il cliente risponde lunedì, la scadenza si sposta esattamente del tempo lavorativo perso.
Lunedì	Avviso al 75 %	L’email di avviso parte quando c’è ancora tempo per intervenire.
Lunedì	Risolta	Il tempo consumato e il rispetto dell’obiettivo vengono registrati e non cambiano più.

Salute SLA su ogni richiesta, con soglie definite per politica
Consumato	Salute
Sotto il 75 %	In salute
75%	A rischio
90%	Critico
100%	Violato
Sospeso	In pausa
Obiettivo rispettato	Completato

JSON per ogni schermata

Un’API JSON in sola lettura copre tutto ciò che mostrano le schermate. Si autentica con una normale chiave API di Redmine e segue gli stessi permessi delle pagine.

Metodo	Endpoint	Restituisce
GET	/sla/issues/:id.json	Lo SLA di una richiesta
GET	/sla/issues.json	Richieste SLA, filtrabili
GET	/projects/:id/sla/issues.json	Richieste SLA di un progetto
GET	/sla/timeline/:id.json	Cronologia di una richiesta
GET	/sla/dashboard.json	Contatori del cruscotto e conformità
GET	/sla/reports/:report.json	Uno qualsiasi dei quattro report
GET	/sla/policies.json	Politiche e relativi obiettivi
GET	/sla/calendars.json	Calendari e orari di lavoro

Leggere lo SLA di una richiesta

Invia la tua chiave nell’header X-Redmine-API-Key. La risposta contiene la politica, il calendario, la salute complessiva e una voce per obiettivo con stato, scadenza e tempo consumato. Usala per mostrare i conti alla rovescia SLA su un wallboard o per alimentare i tuoi report con i dati di conformità.

Sei permessi, assegnati per ruolo

SLA è un normale modulo di progetto Redmine. Attivalo sui progetti che misuri e dai a ogni ruolo solo ciò che gli serve. Gli amministratori di Redmine hanno sempre i due permessi globali.

Permesso	Ambito	Cosa consente
view_sla	Progetto	Vedere il pannello SLA sulle richieste, la lista delle richieste SLA e la cronologia
view_sla_dashboard	Progetto	Vedere il cruscotto SLA
view_sla_reports	Progetto	Vedere ed esportare i report SLA
manage_sla	Progetto	Modificare le impostazioni SLA del progetto e ricalcolare lo SLA di una richiesta
manage_sla_policies	Globale	Creare e modificare politiche e regole di pausa
manage_sla_calendars	Globale	Creare e modificare calendari e festività

Funziona dove già funziona il tuo Redmine

Ambiente	Stato	Note
Redmine 7.x	Supportato	Testato su Redmine 7.0 con Rails 8.1 e Ruby 3.4.2. Le schermate di questa pagina provengono dalla 7.0.
Redmine 6.x	Supportato
Redmine 5.x	Supportato	Richiede il task degli asset dei plugin dopo la migrazione
Redmine 4.x	Supportato	La 4.0 è la versione minima dichiarata dal plugin
Database	Supportato	PostgreSQL, MySQL, MariaDB e SQLite, senza SQL specifico per un database
Gem aggiuntive	Nessuna	Niente Redis, niente Sidekiq. Una voce cron o un timer systemd esegue il controllo in background.
Core di Redmine	Intatto	Nessun file del core viene modificato, quindi gli aggiornamenti di Redmine non ne risentono

Installazione in tre passi

Richiede accesso shell e la possibilità di eseguire task rake. Fai sempre un backup prima di installare un plugin.

Scompattare nella cartella dei plugin

cd /path/to/redmine
# the package arrives by email, or from your download link
unzip redmine_sla-1.0.0.zip -d plugins/

Migrare e riavviare

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

Pianificare avvisi e violazioni

# 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

Attivarlo in Redmine

# 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

Il plugin modifica i file del core di Redmine?

No. Usa l’API dei plugin, gli hook delle viste e il sistema di permessi di Redmine. Dove Redmine non offre hook, il plugin aggiunge piccole patch che si limitano a estendere il comportamento esistente. Nessun file di Redmine viene modificato, quindi l’aggiornamento di Redmine non ne risente.

Che cosa succede agli SLA esistenti se modifico una politica?

Non cambia nulla. Ogni SLA congela la politica con cui è stato creato: obiettivi, soglie, eventi e orari di lavoro. Il dato di conformità del trimestre scorso resta esattamente come è stato riportato. Applicare una politica modificata ai record esistenti è un’azione deliberata dell’amministratore.

Servono Redis, Sidekiq o gem aggiuntive?

No. Il plugin non aggiunge dipendenze da gem e non presuppone alcun sistema di job. Avvisi e violazioni vengono rilevati da un unico comando che si può eseguire più volte senza rischi. Pianificalo con cron, un timer systemd o ciò che usi già.

Clienti o progetti diversi possono avere SLA diversi?

Sì. Scrivi una politica per ogni impegno e assegna a ciascuna le sue condizioni: progetto, tracker, priorità, categoria, assegnatario, gruppo o qualsiasi campo personalizzato. Ogni progetto può inoltre sostituire calendario e fuso orario e limitare le politiche che gli si possono applicare.

E le richieste che esistevano prima dell’installazione?

Le nuove richieste ricevono uno SLA automaticamente. Per quelle esistenti, un task di backfill assegna uno SLA a ogni richiesta che non ne ha ancora uno, per tutti i progetti o per uno solo.

La disinstallazione è sicura?

Sì. Rimuovendo la cartella del plugin, tutte le righe SLA restano nel database. Solo una migrazione esplicita alla versione zero elimina le tabelle. Cancellare i dati di tracciamento mantenendo il plugin installato è un’azione separata, con conferma, disattivata per impostazione predefinita.

Le schermate sono reali?

Sono schermate reali del plugin su Redmine 7.0, prese dal progetto demo che il plugin può generare per te: dieci richieste, una per ogni stato SLA. I numeri mostrano ciò che vedrai per i tuoi progetti, non i risultati di un cliente.