• Website: https://github.com/likehopper/redmine_sla
• Code repository: git@github.com:likehopper/redmine_sla.git
• Redmine plugins directory: https://www.redmine.org/plugins/redmine_sla

redmine_sla provides advanced Service Level Agreement management for Redmine.

It enables precise SLA computation based on:

• Project trackers
• Working calendars (HO / HNO)
• SLA levels and priorities
• Response and resolution terms
• Database-native time-based procedures

SLA compliance is calculated directly at the database level using PostgreSQL or MySQL/MariaDB stored procedures, ensuring:

• Deterministic computation
• Accurate working-hours handling
• High performance on large datasets

Many SLA implementations rely exclusively on Ruby time computations.

This plugin delegates SLA calculation to database stored procedures, allowing:

• Accurate handling of working schedules
• Holiday-aware deadlines
• Efficient computation on large issue volumes
• Predictable and reproducible results

The engine is designed for production environments.

SLA
 ├── SLA Level
 │     └── SLA Terms (Response / Resolution)
 ├── SLA Calendar
 │     ├── Weekly Schedule
 │     └── Holidays
 └── SLA Status Mapping

An SLA is the top-level contract (e.g. "Gold Support", "Standard Support"). It is assigned to one or more project / tracker pairs, so the same SLA definition can be reused across several projects.

An SLA is broken down into one or more SLA Levels. Each level pairs the SLA with a single SLA Calendar and groups the actual SLA Terms: for every combination of SLA Type (e.g. Response, Resolution) and priority — either a native Redmine issue priority or a custom field value — a term defines the committed duration, in minutes.

An SLA Calendar describes when the clock actually runs:

• Weekly Schedule: working hours per day of week (HO / HNO), used to suspend or resume the countdown outside business hours.
• Holidays: non-working days shared across calendars. The match flag decides whether time is simply suspended on that day, or whether an SLA already running is allowed to continue through it.

SLA Status Mapping links each SLA Type to the Redmine issue statuses it should track — for instance "Response" usually maps to the "New" status only, while "Resolution" maps to every status prior to closure ("New", "Assigned", "Feedback", ...). This mapping tells the database procedures which time ranges to accumulate for each type of commitment, independently of any particular SLA, and is what the diagram's "SLA Status Mapping" branch and "SLA Calendar" branch stand for: both are reusable building blocks referenced by SLA Levels/Types rather than data private to a single SLA.

At runtime, the calculation engine combines Terms + Calendar + Status Mapping to compute compliance for every issue in scope — see SLA Compute Explanation for the underlying algorithm.

• PostgreSQL PL/pgSQL or MySQL/MariaDB SLA computation
• Working calendar awareness (HO / HNO)
• Response & resolution deadlines
• SLA compliance percentage
• Configurable update step
• Configurable calculation time zone

Fully manageable through UI and REST API:

• SLAs
• SLA Types
• SLA Statuses
• SLA Holidays
• SLA Calendars
• Weekly schedules
• Calendar-specific holidays
• SLA Levels
• SLA Terms

• SLA assignment per tracker
• Role-based permissions
• SLA visibility control
• SLA columns in issue list
• SLA filtering
• SLA summary in issue view
• Responsive display

• SLA filtering
• SLA columns in time log list

• Manual SLA update task
• Cron-based update support
• CSV-based fixture builder

• English
• French

• Graphical schedule editor
• Tabular SLA term editor
• Improved calendar visualization

• Per-project time zone
• Alert thresholds & notifications
• SLA import (CSV export already available)
• SLA summary in issue reports

• Cache invalidation strategy
• Full functional test coverage

This plugin relies on database-native views and stored procedures, and therefore requires the SQL schema format. In config/application.rb:

config.active_record.schema_format = :sql

This is mandatory for every supported database.

SQLite is not supported.

Ensure PostgreSQL datestyle is set to ISO:

ALTER DATABASE "redmine_db" SET datestyle="ISO,MDY";

Recommended configuration:

config.active_record.default_timezone = :local

Prefer global timezone configuration set to:

Etc/UTC

Before migrating the plugin:

• Load the server time-zone tables, which are required by SLA timestamp conversions:

  mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

• If binary logging is enabled, allow the migration to create stored functions:

  SET GLOBAL log_bin_trust_function_creators = 1;

  The setting can be made persistent with log_bin_trust_function_creators = 1 under [mysqld].

Use Etc/UTC as the server-wide time zone where possible.

1. Copy redmine_sla into Redmine's plugins directory\
2. Run:

bundle install

3. Migrate:

rake redmine:plugins:migrate NAME=redmine_sla

4. Restart application server

Plugin is ready to use.

rake redmine:plugins:migrate NAME=redmine_sla VERSION=0

Then remove the plugin folder:

rm -r redmine_sla

Restart application server.

• Contributing
• Code of Conduct
• Security policy
• Functional tests
• Conceptual Data Model
• Step-by-step use case
  • Example 01
  • Example 02
  • Example 03
  • Example 04
  • Example 05
• SLA Compute Explanation
• Plugin settings
• API Rest for SLA
• Tasks
• Change log
• License

Icons created by Magnific