Does the plugin modify Redmine core files?

No. It uses Redmine’s plugin API, view hooks and permission system. Where Redmine offers no hook, the plugin adds small patches that only append to the existing behaviour. No Redmine file is edited, so upgrading Redmine is unaffected.

What happens to existing SLAs when I edit a policy?

Nothing changes. Each SLA freezes the policy it was created with: targets, thresholds, events and working hours. Last quarter’s compliance figure stays exactly as it was reported. Applying an edited policy to existing records is a deliberate administrator action.

Does it need Redis, Sidekiq or extra gems?

No. The plugin adds no gem dependency and assumes no job system. Warnings and breaches are detected by one command that is safe to run repeatedly. Schedule it with cron, a systemd timer, or whatever you already use.

Can different customers or projects have different SLAs?

Yes. Write one policy per commitment and give each one conditions: project, tracker, priority, category, assignee, group or any custom field. Each project can also override the calendar and time zone, and restrict which policies may apply to it.

What about issues that existed before I installed it?

New issues get an SLA automatically. For existing issues, a backfill task assigns SLAs to every issue that does not have one yet, for all projects or for one project.

Is uninstalling safe?

Yes. Removing the plugin folder keeps every SLA row in the database. Only an explicit migration to version zero drops the tables. Deleting tracking data while the plugin stays installed is a separate, confirmed action that is switched off by default.

Are the screenshots real?

They are real screens from the plugin on Redmine 7.0, taken from the demo project the plugin can generate for you: ten issues, one in each SLA state. The figures show what you will see for your own projects, not results from a customer.

Redmine SLA

Support

5.0 (0)·New installs

A four-hour SLA is not four hours. Response and resolution measured in working time — your calendars, your holidays, your pause rules — with warning, critical and breach detection.

$199 / single server

User guide

Multiple servers: $399

5-working-day refund12 months updatesSource included

The SLA dashboard of a Redmine project: a 75% compliance ring with first response at 80% and resolution at 66.7%, average response of 35 minutes and average resolution of 12 hours 40 minutes, counters for 10 SLA issues of which 6 are running, 2 at risk, 3 breached, 1 paused and 2 completed, a colour-coded health bar, tables of at-risk and breached issues with due dates, and compliance per SLA policy. — Project › SLA Compliance by target, live counters, and every at-risk and breached issue with its due date.

Redmine: 4, 5, 6 and 7
Targets: 4 independent clocks
Databases: PostgreSQL, MySQL, MariaDB, SQLite
Reports: 4, with CSV export
Extra gems: None
Core files changed: None

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.

Your clock stops when your team goes home

Subtracting two timestamps punishes you for weekends. Redmine SLA walks your business calendar and counts only the minutes you are open, so a four-hour target raised late on Friday is due on Monday, not the same night.

A four-hour resolution target on a Monday to Friday, 09:00 to 18:00 calendar
Issue raised	Working time counted	Due	Wall clock
Tuesday 09:30	4h, uninterrupted	Tuesday 13:30	4 hours
Friday 17:00	1h on Friday, 3h on Monday	Monday 12:00	67 hours
Friday 17:00, Monday a holiday	1h on Friday, 3h on Tuesday	Tuesday 12:00	91 hours
Any time, on a 24×7 calendar	4h elapsed	Four hours later	4 hours

Calendars support split shifts, their own time zone, one-off and recurring holidays, and special working days.

Four clocks, each with its own rules

Set only the targets you actually promise. Each one starts, pauses and stops on its own event, so “waiting for customer” can freeze resolution while first response keeps running.

First response: someone answered

Stops on the first public comment from anyone other than the author. What counts as a reply is set per policy.

Acknowledgement: someone owns it

Stops when the issue is assigned, or when it reaches a status you choose.

Resolution: the problem is fixed

Stops when the issue reaches a closed status, or one of the resolution statuses you pick.

Closure: the ticket is done

A separate target for the final close, for teams that resolve first and confirm with the customer later.

It looks like Redmine, because it is

No iframe, no separate app, no second login. These are real screens from the plugin on Redmine 7.0, showing a demo project with issues in every SLA state.

Agents: the SLA panel on every issue

One row per target, with its state, the time left, how much of the target is used and the exact due date.

A Redmine bug, Checkout page intermittently times out, with an SLA panel under its attributes. The panel is marked At risk and shows the policy SLA demo - Critical on a 24x7 calendar in UTC. First response is At risk with a few minutes remaining and a progress ring above 80%. Resolution is Healthy with over three hours remaining. Links to the SLA timeline and to recalculate sit below. — Issue page First response is at risk with minutes to go, while resolution is still healthy. The countdown updates live, and the panel names the policy, calendar and time zone it is measured against.

The SLA panel of a paused issue: first response completed in 5 minutes against a 30 minute target, and resolution paused at 50% with 2 hours of 4 consumed. — Paused The agent replied in 5 minutes, then the issue moved to a waiting status. Resolution is frozen at 2h of 4h until the customer answers.

The SLA timeline for the same bug: timers started for first response and resolution, SLA started, first-response timer completed, SLA assigned to the Critical policy, and resolution timer paused, each with a timestamp and the user who caused it. — SLA timeline Every start, completion, pause and breach in order, with who caused it. This is the record you show when a customer disputes a number.

Team leads: the queue, sorted by what is about to go wrong

Filter by status, health, policy or breached, sort by due date, export to CSV. The same fields are filters and columns in Redmine’s own issue list.

The SLA issues list with filters for SLA status, SLA health, policy and breached. Ten issues are listed with project, SLA policy, status, a coloured health badge of paused, completed, breached, critical, at risk or healthy, the first response and resolution result or time remaining, and the SLA due date. — SLA issues Ten issues across every health state: paused, completed, breached, critical, at risk and healthy, each with the time remaining or the overrun for both targets.

Managers: reports you can put in front of a customer

Compliance, response time, resolution time and breaches, filtered by period, policy, tracker and priority. Every report exports to CSV.

The SLA reports page on the compliance tab, with period shortcuts from 7 days to all time, filters for SLA policy, tracker and priority, and a compliance summary of 75% with first response at 80% and resolution at 66.7%. — Compliance Targets met against targets measured, split by first response and resolution.

The response time report: median 10 minutes, average 35 minutes, minimum 5 minutes, maximum 2 hours over 5 measured responses, and a distribution bar chart with buckets from 15 minutes to more than 3 days. — Response time Median, average, fastest and slowest, plus a distribution that shows where the outliers are.

The breaches report listing four breaches in the period with issue, project, SLA policy, priority, assignee, breach type of first response or resolution, SLA due date, actual date and breach duration. — Breaches Which target was missed on which issue, when it was due, when it was actually met, and by how long it overran.

Admins: policies written in plain words

“When the issue’s Priority is one of Urgent, Immediate.” Conditions use real names from pickers, not record IDs. Durations accept 30, 4h or 1d 4h.

The SLA policy form: name, description, active, default and position, then targets for first response, acknowledgement, resolution and closure, a business calendar and time zone, and a conditions table where Priority is one of Urgent and Immediate. — Targets and conditions The four targets, the calendar they are measured on, and the conditions that decide which issues the policy applies to.

The events section of the policy form: the SLA starts on issue creation, first response stops on the first public comment and ignores updates from the issue author, acknowledgement stops when the issue is assigned, and resolution and closure stop when the issue reaches a closed status or one of the selected statuses. — Events Choose what starts each clock and what stops it.

Thresholds on the policy form set warning at 75% and critical at 90% with notifications on, above a pause rules table where one status pauses Resolution and Closure but not First response or Acknowledgement. — Thresholds and pause rules Warn at 75%, go critical at 90%, and tick which targets each status freezes.

The working hours of a business calendar: 09:00 to 18:00 Monday to Friday, weekends empty, an optional second period per day for split shifts, and a shortcut to apply Monday to Friday 09:00 to 18:00. — Business calendar Working hours per weekday, a second period for split shifts, a time zone and holidays, or simply 24×7.

The SLA tab in Redmine project settings: SLA enabled, inherit from parent project, business calendar, default SLA policy and time zone, plus checkboxes restricting which SLA policies the project may use. — Project settings Switch SLA on per project, inherit from the parent, override the calendar, or restrict which policies may apply.

Operations: one place to see that it is all working

The SLA administration page: a setup checklist for business calendars, policies, enabled projects, global pause rules and background processing with the time of the last run, an overview with counters and 75% compliance, and links to policies, calendars, holidays, pause rules, email templates, settings, reports, SLA issues and the audit trail. — Administration › SLA A setup checklist that tells you what is missing, when the background task last ran, and a live overview.

The SLA audit trail: a filterable table listing when each SLA was assigned or recalculated, by which user, on which object, with details such as the policy name and issue ID. — Audit trail Who assigned, changed or recalculated which SLA, and when.

Everything a service desk actually argues about

Disputes are rarely about whether a ticket was late. They are about which hours counted, when the clock should have stopped, and what the target was at the time.

Working hours, done properly

Weekly schedules with split shifts, per-calendar time zones, fixed and recurring holidays and special working days. 09:00 stays 09:00 across daylight saving changes.

Waiting on the customer

Pause rules per status, globally or per policy. Only working time is given back, so a pause over the weekend costs nothing.

Warning, critical, breach

Thresholds fire before the deadline. Each notification is sent once through Redmine’s own mailer, with templates you can edit per event and language.

The right policy for each issue

Match on project and subprojects, tracker, priority, status, category, author, assignee, group or any custom field. Lower positions win when several policies match.

Inside the issue list

SLA policy, status, health, breached, due date and time remaining as filters and columns in Redmine’s issue list: sortable, groupable and exportable.

Edits do not rewrite history

Every SLA keeps a snapshot of the policy it started with. Changing a target next quarter leaves last quarter’s numbers alone. Recalculating is a deliberate admin action.

What happens to one issue

A critical bug raised on a Friday afternoon, on a Monday to Friday 09:00 to 18:00 calendar, with a 30-minute first response target and a four-hour resolution target.

When	Event	What the plugin does
Fri 15:00	Raised	The first matching policy attaches and its clocks start. Three working hours are left today, so one carries over to Monday.
Fri 15:20	First reply	A public comment from an agent stops the first response clock at 20 minutes, inside its 30-minute target.
Fri 16:00	Waiting	Resolution pauses. When the customer answers on Monday, the due date moves forward by exactly the working time lost.
Monday	Warning at 75%	The warning email goes out while there is still time to act on it.
Monday	Resolved	The time consumed and whether the target was met are recorded, and never change again.

SLA health on every issue, with thresholds set per policy
Consumed	Health
Below 75%	Healthy
75%	At risk
90%	Critical
100%	Breached
On hold	Paused
Target met	Completed

JSON for every screen

A read-only JSON API covers everything the screens show. It authenticates with a normal Redmine API key and follows the same permissions as the pages.

Method	Endpoint	Returns
GET	/sla/issues/:id.json	The SLA of one issue
GET	/sla/issues.json	SLA issues, filterable
GET	/projects/:id/sla/issues.json	SLA issues of one project
GET	/sla/timeline/:id.json	Timeline of one issue
GET	/sla/dashboard.json	Dashboard counters and compliance
GET	/sla/reports/:report.json	Any of the four reports
GET	/sla/policies.json	Policies and their targets
GET	/sla/calendars.json	Calendars and working hours

Read one issue’s SLA

Send your key in the X-Redmine-API-Key header. The response carries the policy, calendar, overall health, and one entry per target with its state, due date and time consumed. Use it to put SLA countdowns on a wallboard, or to feed compliance figures into your own reporting.

Six permissions, granted per role

SLA is a standard Redmine project module. Enable it on the projects you measure and give each role only what it needs. Redmine administrators always have the two global permissions.

Permission	Scope	What it allows
view_sla	Project	See the SLA panel on issues, the SLA issue list and the timeline
view_sla_dashboard	Project	See the SLA dashboard
view_sla_reports	Project	See and export the SLA reports
manage_sla	Project	Edit the project’s SLA settings and recalculate an issue’s SLA
manage_sla_policies	Global	Create and edit policies and pause rules
manage_sla_calendars	Global	Create and edit calendars and holidays

Runs where your Redmine already runs

Environment	Status	Notes
Redmine 7.x	Supported	Tested on Redmine 7.0 with Rails 8.1 and Ruby 3.4.2. The screenshots on this page are from 7.0.
Redmine 6.x	Supported
Redmine 5.x	Supported	Needs the plugin assets task after migrating
Redmine 4.x	Supported	4.0 is the minimum version the plugin declares
Databases	Supported	PostgreSQL, MySQL, MariaDB and SQLite, with no database-specific SQL
Extra gems	None	No Redis, no Sidekiq. One cron entry or systemd timer runs the background check.
Redmine core	Untouched	No core file is edited, so Redmine upgrades are unaffected

Install in three steps

Requires shell access and the ability to run rake tasks. Always back up before installing a plugin.

Unpack into your plugins folder

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

Migrate and restart

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

Schedule warnings and breaches

# 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

Turn it on 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