Updated: December 4, 2024

Setting up Alerts for a Project/Employee

Enji allows users to arrange specific alerts for particular employees and activities. This guide will help users create alerts and assign them.

Bots, Standups and Alerting

Follow these steps to arrange for alerts to be sent to a project or individual employee:

  1. Open the project Settings.
  2. Access the "Project Alerts" tab (for an individual, configured in the "Individual Alerts" tab).
  3. Choose the days of the week and the time for sending alerts.
  4. Enable the desired alerts.
  5. Save.

Individual alert settings override project settings.

Alerts in Enji

Below, please find a description of the alerts available in Enji.

Report tasks in status with no worklogs

Issue: A teammate moves a task to the "In progress" status but forgets about it, switching to another task. The team is waiting for the task, but no results have been received for several days. Extra communication time is spent.

Solution: An alert is sent when a person switches a task's status to "In progress" but has not logged any time in the task for N hours. Worklogs serve as evidence of work and results.

In the settings, complete the following fields:

  1. Target Channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. Recipients: Choose who receives the alert – the general project channel, the teammate, or the manager based on the project's SOW. "Project" sends the alert to the channel mentioned in point 1.
  3. Status to be tracked: Enter the name of the status from the workflow in Jira. Any statuses can be specified, not only "In progress." Separate multiple statuses with a comma (,).
  4. Time limit (hours): Specify the number of hours after which the alert should trigger. The countdown starts from the time the task is moved to the configured status. Format → 8h 30m.
  5. Sending time: Set the time for alert delivery.

Notify if a team member has exceeded the daily hours limit

Issue: A team member has an allocated scope of work in a project for the day, but they consistently exceed this scope, which can eventually lead to burnout.

Solution: An alert notifies when a team member logs the allocated number of hours in a project for the day. The daily hour limit is derived from the project's Statement of Work (SOW).

Configure these fields:

  1. Target channel: Specify the channel to send the alert. If not provided, the alert will be sent to the channel specified under the General tab.
  2. Recipients: Choose the recipients of the alert:
    Project: Sends the alert to the channel defined in point 1.
    Violator: Notifies the team member exceeding the allocated hours.
    Manager: Sends the alert to the manager based on the SOW of the project.

Notify if a team member has exceeded the monthly workload limit

Issue: A teammate has a scope of work in the project but tends to log all hours at the beginning of the month or keeps logging with the risk of burnout.

Solution: An alert notifies when a teammate has logged the allocated hours for the current month in the project. The alert is sent at intervals based on the specified settings. The monthly hour limit is taken from the project's Scope of Work (SOW).

In the settings, complete the following fields:

  1. Target channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. Recipients: Choose who receives the alert – the general project channel, the teammate, or the manager based on the project's SOW. "Project" sends the alert to the channel mentioned in point 1.
  3. Checkpoint (%): Indicate the percentage of logged hours after which the alert should trigger. For example, specifying 60% with a 160-hour scope means the alert triggers when the teammate logs 96 hours in the current month.
  4. Checkpoint interval (%): Specify the frequency of alert triggers in percentages. If set to 10%, the alert triggers every 10% of logging.

A red siren icon indicates the teammate has exceeded the hour limit (100%+). The teammate will be tagged.

Notify about hanging merge requests in the repository

Issue: Merge requests remain idle for an extended period and are forgotten.

Solution: An alert triggers when there are merge requests that have not been merged for several hours. It is sent once a day.

In the settings, complete in the following fields:

  1. Target channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. Recipients: Choose who receives the alert – the general project channel, the teammate, or the manager based on the project's SOW. "Project" sends the alert to the channel mentioned in point 1.
  3. Time limit: Indicate the number of hours after which the alert should trigger. For example, set to 4 hours.
  4. Sending time: Specify the sending time (UTC).

Notify if a team member has several tasks under one status

Issue: A teammate moves 10 tasks to the same status at once, then struggles to understand what to work on. The team also has trouble figuring out what they are working on.

Solution: The alert is sent when a developer has accumulated several tasks in one status.

In the settings, complete the following fields:

  1. Target channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. Recipients: Choose who receives the alert – the general project channel, the teammate, or the manager based on the project's SOW. "Project" sends the alert to the channel mentioned in point 1.
  3. Number of issues and their statuses: Enter the allowable number of tasks and the name of the status. Multiple statuses can be specified and must be separated by a comma (,). Format → 3 In progress, 2 To Do, 1 Under review.
  4. Issue type to be tracked: Enter the type of task to track. Format → Task, Bug.

Report if branch/commit/MR title is missing Jira issue key

Issue: Teammate does not specify the task they are working on in the branch, commits, and creates Merge Requests (MRs). It requires opening Jira, and searching for the exact task being discussed. Time is wasted unnecessarily.

Solution: Alerts when a developer has not added a link to the Jira task in the branch, commit, and MR titles. Sent once a day.

In the settings, complete the following fields:

  1. Target channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. Recipients: Choose who receives the alert – the general project channel, the teammate, or the manager based on the project's SOW. "Project" sends the alert to the channel mentioned in point 1.
  3. Sending time: Specify the sending time (UTC).
  4. Exceptions: Enter keywords in the branch, commit, and MR titles that do not contain a link to the Jira task. For example, creating an MR like "push to production." If a keyword is added in the settings, the alert will skip such cases and will not trigger.

Daily/Weekly report

To run a report, a project needs to be set up with team members actively contributing data to the project.

This feature is designed to provide regular insights for the team, management, and project stakeholders, detailing the time spent yesterday or over the past week.

The report format is standardized for Slack, Chatwork, and Telegram:

Every day, at a specified time, a report is sent, listing the number of hours spent, commits made to repositories by the team, and the count of alerts recorded.

The Enji Bot tags individual employees in the following situations:

  • A team member logged fewer hours than planned for yesterday.
  • A team member has no committed activities from yesterday.
  • A team member didn't submit a stand-up report for the previous day.


To configure a report

  1. Open Project settings -> Project Alerts.
  2. In Business Days, select the days.
  3. Find Daily/Weekly Report in the list.
  4. Enable it, choose the channel for delivery, and set the time.
  5. Save.

Send Jira/repo activities from the previous day in response to the stand-up

Issue: A teammate worked on many tasks yesterday but cannot remember exactly what was done.

Solution: The bot sends in a thread a list of tasks and MRs the team member worked on yesterday.

A task is considered worked on if:

  1. A task is created
  2. Changes in the "Original Estimate" field. If a subtask is modified, it is considered an activity in the main (parent) task
  3. Changes in the task status
  4. A comment is left


If there are no matches based on these criteria, the bot will not respond to the stand-up. If the developer is not added to the Scope of Work (SOW), the bot will not respond to the stand-up.

Complete the following fields in the settings:

  1. Target channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. All activities: Check the box to see the developer's activity across all projects they are involved in.

Stand-up reminder

Problem: A team member forgot to submit their stand-up report on time.

Solution: The alert will remind the team member to submit their standup and send additional notifications if the standup is still not submitted.

In the settings, complete the following fields:

  1. Remind every (minutes): The interval at which reminders will be sent.
  2. Reminder limit (in repetitions): The number of times the reminder should be sent.
  3. Daily deadline for stand-up: Specify the days of the week when stand-ups are required and the time by which they must be submitted.

Notify if work description does not comply with limits

Issue: Teammates may write too short or too long worklog descriptions. Both cases are unacceptable.

Solution: An alert highlights excessively short or long text in a worklog. It is sent once a day.

In the settings, complete the following fields:

  1. Target channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. Recipients: Choose who receives the alert – the general project channel, the teammate, or the manager based on the project's SOW. "Project" sends the alert to the channel mentioned in point 1.
  3. Counting: Indicate the basis for triggering the alert – the word or character count in the work log.
  4. Min/max: Set the boundaries for the alert trigger. You can specify both parameters or just one.
  5. Sending time: Specify the sending time (UTC).

Notify if worklog time exceeds the limit

Issue: A teammate logs work hours once a day and logs 8 hours at once. This is unacceptable as it compromises process transparency.

Solution: An alert is sent when a single worklog exceeds the specified limit. It is sent once a day.

In the settings, complete the following fields:

  1. Target channel: Specify the channel to send the alert. The alert will be sent to the channel indicated in the General tab if not specified.
  2. Recipients: Choose who receives the alert – the general project channel, the teammate, or the manager based on the project's SOW. "Project" sends the alert to the channel mentioned in point 1.
  3. Worklog hours limit: Indicate how many hours can be logged in a single work log. Format → 1h 30m.
  4. Sending time: Specify the sending time (UTC).

A red siren icon indicates that the work log is logged 50% or more over the limit. For example, if the limit is set to 2 hours, and 3 hours or more are logged.

Notify if a team member does not have worklogs in 24 hours

Problem: A team member forgets to log work on time, making it difficult for the PM to track all worklogs in the project.

Solution: The alert sends a notification once a day, tagging project team members who have not logged any work in the past 24 hours. This saves the PM time and motivates team members to log their work on time.

In the settings, complete the following fields:

  1. Target channel: Specify the channel where the alert should be sent. If not specified, the alert will be sent to the channel listed under General -> Team Channel.
  2. Recipients: Choose who should receive the alert: the project's general channel, the individual who missed the worklog, or the manager based on the project's SOW.

Alerting is based on data from the last 24 hours after activation.