SLA in Redmine 5.1: plugin selection and customization | Guide

SLA in Redmine 5.1: Analyzing Non-Working Plugins and the Path to Customization

In the absence of automated metrics in task management, managers are forced to manually monitor deadlines, leading to errors and reduced efficiency. For companies using Redmine 5.1, implementing SLA (Service Level Agreement) is critically important. However, searching for a ready-made solution among plugins revealed serious compatibility and functionality issues.

Setting Up a Test Environment in Docker

For safe plugin testing without risking the production system, an isolated test environment was deployed using Docker. The configuration included separate containers for Redmine and PostgreSQL, a fixed Redmine 5.1 version, and access only via localhost. The key solution was mapping local directories for files and plugins, which avoided rebuilding the image on every change.

Example docker-compose.yml configuration:

services:
   postgres:
     image: postgres:16
     volumes:
       - db_data:/var/lib/postgresql/data
     environment:
       POSTGRES_USER: "redmine"
       POSTGRES_PASSWORD: "password"
       POSTGRES_DB: "redmine"
       PGDATA: "/var/lib/postgresql/data"
     restart: always
   redmine:
     image: redmine:5.1
     ports:
       - 80:3000
     volumes:
       - ./local-files:/usr/src/redmine/files
       - ./local-plugins:/usr/src/redmine/plugins
     depends_on:
       - postgres
     environment:
       REDMINE_DB_POSTGRES: "postgres"
       REDMINE_DB_USERNAME: "redmine"
       REDMINE_DB_PASSWORD: "password"
       REDMINE_DB_DATABASE: "redmine"
     restart: no
     

volumes:
  redmine_data:
  db_data:  

The environment was launched with the command docker-compose up -d. After a successful start (no errors occurred), the author logged into the web interface (login: admin, password: admin) and prepared test data: trackers, a project, and issues. Before installing plugins, a database backup was created via volume export in Docker Desktop.

Plugin Testing Methodology

Each plugin was tested individually to rule out conflicts. The process involved three steps:

• Copying the plugin folder to the ./local-plugins directory on the host machine.
• Installing dependencies via bundle install inside the Redmine container.
• Running migrations (if needed) with the command rake redmine:plugins:migrate.

During dependency installation, typical issues arose with missing gems, for example:

Could not find gem 'business_time (>= 0.13.0)'
Could not find gem 'holidays (>= 7.1.0)'

The solution was to manually install the missing components:

gem install business_time
gem install holidays

This step was mandatory for most solutions tested.

Plugin Compatibility Analysis with Redmine 5.1

Eight plugins matching the SLA control functionality were tested. Key requirements for the solution:

• Monitoring response time to issues.
• Monitoring time to fully resolve issues.
• Ability to filter issues by specified parameters.

Test results:

• reporting_sla (last update 18.11.2025): incompatible with Rails/Redmine versions. Requires deep modification.
• likehopper/redmine_sla (12.02.2026): works only with PostgreSQL, but Oracle was used in the test environment. High performance due to offloading logic to the DB.
• redmine_issue_sla (29.01.2018): outdated plugin for Redmine 3.x, does not start on version 5.1.
• redmine_sla_timer (12.07.2020): no description and incompatible with the current version.
• redmine_sla_ola (12.07.2020): the only working option, but requires additional setup—adding custom fields products and first_reply.
• agile (03.12.2025): handles project management tasks but does not provide SLA functionality.
• RedmineUP Helpdesk: commercial solution with support, but does not cover all scenarios and requires budget.

SLA Implementation Recommendations

After analyzing the options, no ready-to-use "out-of-the-box" solution for Redmine 5.1 was found. Organizations have three paths forward:

• Purchase a commercial solution (e.g., RedmineUP). Pros: support, regular updates. Cons: security policy restrictions, mismatch with specific requirements.
• Modify an existing plugin (redmine_sla_ola). Pros: core functionality already implemented. Cons: need for customization to fit processes, risks during Redmine updates.
• Develop a custom plugin. Pros: exact match to business processes, no unnecessary features. Cons: time investment (estimated 3-5 days for a demo version).

For organizations with strictly regulated SLA processes, ignoring automation leads to more missed deadlines. When choosing an implementation path, consider not only current costs but also TCO (Total Cost of Ownership). Commercial solutions may require annual license fees, while customization solves the issue once with minimal ongoing costs.

Key Takeaways

• Version compatibility is critical: Most plugins have not been updated for Redmine 5.1, making them non-functional without modification.
• Additional setup required: Even "working" plugins need customization (e.g., adding fields), increasing effort.
• Docker is essential: Testing in an isolated environment prevents damage to the production system and speeds up rollbacks.
• Gem dependencies are a common issue: Missing business logic gems (business_time, holidays) require manual installation, complicating the process.
• Customization vs. commercial solutions: With a limited budget and clear requirements, developing your own plugin saves resources long-term.

— Editorial Team