DEV Community

Cover image for Let JIRA Do the Work: Monitoring (Part 3)
Ekaterina Vikulova
Ekaterina Vikulova

Posted on

Let JIRA Do the Work: Monitoring (Part 3)

Intro

I’ve cooked up a bunch of time-saving Jira automations: the kind that save time, cut down manual work and fit projects of any size. To keep things clear, I’ve split them into three categories: Order-bringing, Life-simplifying, and Monitoring, with each getting its own article.

The first part was all about structure: status transitions, clean closures, and keeping your backlog tidy. It also includes a quick overview of how our project is set up, which helps explain why I use certain fields.

The second part focused on everyday relief: assigning the right people, syncing frontend and backend, unblock waiting tasks and removing extra clicks from your daily routine.

Now, in this final part, it’s time for Monitoring automations. The ones that help you stay informed, spot bottlenecks early, and keep your project under control without micromanaging.

Monitoring

These rules focus solely on sending alerts and do not make any changes to the issues.

project-rule-12: Send Release Note to Slack

What it does:
When an issue is transitioned to Closed, it checks the issue type and whether the Fix Version field is filled in. If a version is specified, it sends a message to a dedicated Slack channel with the release number and the release note.

How it works:

– Triggered when the issue transitions to Closed (Issue transitioned);
– Check the issue type to include only parent tasks and avoid spamming (JQL condition);
– Send a Slack notification (Send Slack message).
Enter fullscreen mode Exit fullscreen mode

How it looks:
project-rule-12 Send Release Note to Slack

Some details:

project-rule-13: List Ready Backend/Frontend Tasks

What it does:
Once a day, it checks for new Backend and Frontend tasks that are ready to be picked up. You can split them by profile and/or set up separate automations for each issue type.

For example, you can set up separate automations with different icons for clarity:
🛠️ Backend: new features
🐞 Backend: new bugs
🎨 Frontend: new features
🐛 Frontend: new bugs

How it works:

– Runs daily on weekdays based on a cron schedule, checking for issues that match specific types, components, have no assignee, and were created 1 day ago (Scheduled);
– Sends a Slack notification (Send Slack message).
Enter fullscreen mode Exit fullscreen mode

How it looks on Backend example:

project-rule-13 List Ready Backend Tasks

project-rule-13 List Ready Backend Tasks

Some details:

  • :ruby: – the icon that will be shown in Slack;
  • {{issue.issuetype.name}} – the issue type;
  • {{issue.priority.name}} – the issue priority;
  • https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}} – the issue key with a clickable link;
  • {{issue.summary}} – the issue summary/title;
  • {{issue.labels}} – all labels;
  • {{issue.components.name}} – all components;
  • @{{issue.assignee.name}} – will mention the assignee in Slack if their usernames match between Jira and Slack;
  • {{issue.customfield_11406}} – a custom field indicating the target quarter for implementation.

How it looks in Slack:

project-rule-13 List Ready Backend Tasks in Slack

project-rule-14: Monitor Stuck In Review

What it does:
On weekdays, it checks for issues in the “In Review” status that haven’t been updated recently. It adds a comment mentioning the Assignee, and also sends a message to the manager saying “Check why this is stuck.”

This is useful if your team strictly follows status transitions and doesn’t forget to keep them updated.

How it works:

– Runs daily on weekdays based on a cron schedule (Scheduled);
– Uses the following JQL filter: status = "In Review" AND updated < -5d;
– Adds a comment to the issue, mentioning the assignee by name: {{assignee.displayName}} (Comment on issue);
– Sends a Slack message to the manager in a designated channel.
Enter fullscreen mode Exit fullscreen mode

How it looks:

project-rule-14 Monitor Stuck In Review

project-rule-14 Monitor Stuck In Review

project-rule-14 Monitor Stuck In Review

Some details:

  • :what: – the icon that will be shown in Slack;
  • https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}} – the issue key with a clickable link;
  • {{issue.summary}} – the issue summary/title;
  • {{issue.assignee}} – the assignee, shown by username for brevity;
  • {{issue.updated.jqlDateTime}} – the last updated time of the issue.

Risk: If a comment was added, the issue won’t be included in the report because its Updated field will change. In our case, this happens very rarely (almost never), so this level of checking is sufficient.

project-rule-15: Priority Check for Blocked Tasks

What it does:
For high-priority issues in the Open or Waiting status, it checks the priority of their blockers and sends a notification. This helps catch cases where an important task is blocked by something Minor and ends up stuck in the queue.

How it works:

– Runs daily on weekdays based on a cron schedule (Scheduled);
– Uses JQL filters to find relevant issues: importantly, filters out issues without blockers:
  status IN (Waiting, Open) AND issueLinkType IN ("is blocked by") AND priority IN (Major, Critical, Blocker, ASAP)
– Adds an extra condition to exclude closed or unrelated blocking issues, and to skip sub-tasks:
  status != Closed AND type NOT IN (Backend, Frontend) (Related issues condition);
– Sends a Slack message to the manager in a dedicated channel.
Enter fullscreen mode Exit fullscreen mode

How it looks:

project-rule-15 Priority Check for Blocked Tasks

project-rule-15 Priority Check for Blocked Tasks

Some details:

project-rule-16: Log Work Report

What it does:
Sends a notification about logged work hours. It’s used for tracking time for team members who are paid on a per-hour basis.

How it works:

– Triggered when work is logged on an issue (Work logged);
– Filters by the user who added the work log (User condition);
– Sends a Slack message to the manager in a designated channel.
Enter fullscreen mode Exit fullscreen mode

How it looks:

project-rule-16 Log Work Report

project-rule-16 Log Work Report

Some details:

  • :time-zone-fyi: – the icon that will be shown in Slack;
  • https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}} – the issue key with a clickable link;
  • {{issue.summary}} – the issue summary/title;
  • {{issue.assignee.displayName}} – the assignee’s name;
  • {{initiator.accountid}} – the username of the initiator who added the work log;
  • {{#math}}{{issue.fields.timespent}} / 3600{{/}}h – total time logged in the issue (in hours);
  • {{issue.updated.jqlDateTime}} – the timestamp of the last update to the issue (server time).

How it looks in Slack:

project-rule-16 Log Work Report in Slack

Tips & Tricks

If you’re using custom fields but don’t have access to the database, you can find the correct smart value name via the REST API:
https://jira.yourdomain.com/rest/api/latest/issue/ISSUE-KEY,
where ISSUE-KEY is any issue key from your project that includes the field you need.

If your Jira instance has many projects, make sure to specify exact project names in your conditions. Otherwise, you might accidentally move issues from other teams.

Whenever possible, prefer Scheduled rules with different time triggers instead of reacting to every status change. If your instance has a high volume of issue transitions, frequent triggers can overload Jira, causing delays or strange behaviour.

Don’t set yourself as the Actor in automation rules. Create a dedicated technical user so all automation activity is clearly separated in the issue history. Otherwise, you may end up wondering why your avatar is doing things you don’t remember.

If you're using Slack notifications, set up separate channels for different types of alerts. Without that separation, helpful updates can become just noise.

Don’t be afraid to create multiple automation rules that send messages to Slack or email – just make sure to review them regularly. If everything is running smoothly, it’s often better to disable them. In fact, I recommend adding notifications to all new rules at first, so you can track whether they’re working as expected.

Try to keep Slack messages short and scannable, ideally one line. If, over time, you notice some data isn’t useful – don’t hesitate to trim it down.

Use different emojis at the beginning of Slack messages to distinguish message types. Clarity makes everything easier.

Further Reading

Before You Go

This wraps up the final part of the series and I hope it sparked a few ideas for automations in your own projects. ;)

From structure to speed to visibility, smart Jira rules can turn routine into rhythm and give your team more space to focus on what really matters.

Got similar automation tips or favourite rules? Share them in the comments! I’d love to see what others are doing and using!

Top comments (0)