Recur for Jira — documentation
Recur creates Jira issues on a schedule — weekly reports, monthly maintenance, quarterly access reviews, certificate renewals. Jira Cloud has no native way to do this (JRACLOUD-5185 was closed as Won't Do), and Automation for Jira reacts to events rather than to a calendar.
Recur is built on Atlassian Forge. There are no external servers and no data leaves Atlassian's infrastructure, so there is nothing extra for a vendor security review to look at.
Getting started
- Open a Jira project you administer and pick Recurring Tasks in the project menu.
- On the empty state, choose one of the three starter templates — Weekly report, Monthly maintenance check, Quarterly review — or start from scratch. Starters arrive with the project, issue type and time zone already filled in.
- Check the preview panel. It lists the next ten runs as you type, in the template's own time zone.
- Save. The template appears in the table with its cadence, its next run and, from then on, the last issue it created.
Only project administrators see the create and edit controls. Everyone else in the project sees the list read-only.
What a template contains
| Field | Notes |
|---|---|
| Name | How the template is listed. Not the issue summary. |
| Issue type | Any non-subtask type in the project. |
| Summary | Supports {{date}} and {{n}}. |
| Description | Plain text. Blank lines start a new paragraph; it is converted to Atlassian Document Format when the issue is created. |
| Assignee | Unassigned, fixed person, default (leaves it for the project's own rule), or rotate through a list. |
| Priority, labels, components | Optional. |
| Due in N days | The due date is set to the creation date plus N days, counted in the template's time zone. |
Variables
-
{{date}}— the date of the run, as a calendar date in the template's time zone. An occurrence at 01:00 Europe/Vilnius on 20 August is2026-08-20, even though the underlying instant is 22:00 UTC on the 19th. -
{{n}}— how many times this template has run, starting at 1. Useful for TLS renewal check #4.
Assignee rotation
In rotate mode, Recur walks the list in order and wraps around. Before it assigns anyone it checks that the account is still active; a deactivated member is skipped, the issue goes to the next person, and the run history records a warning. If nobody in the rotation is still active, the issue is created unassigned rather than not created at all.
Schedules and time zones
Every template picks one IANA time zone. Occurrences are generated as local calendar dates first, the wall-clock time is applied last, and only then is the result converted to UTC. That is why 09:00 Europe/Vilnius stays 09:00 across a daylight saving change even though the UTC instant moves.
Two cases have no objectively right answer, so Recur picks one and holds to it:
| Situation | Behaviour |
|---|---|
| The wall-clock time does not exist (spring forward, e.g. 02:30 on a US switch day) | Runs at the first equivalent instant after the gap |
| The wall-clock time happens twice (autumn fall-back) | Runs once, at the earlier of the two |
Month ends work the same way: the 31st falls back to the last day of shorter months, so “monthly on the 31st” runs on 28 February, or the 29th in a leap year.
Cadences available: every N days; every N weeks on chosen weekdays; every N months on a day of the month; every N months on the nth weekday (first Monday, last Friday). A series can run forever, until a date, or for a fixed number of occurrences.
When exactly an issue appears
Within the hour it is due. Recur wakes up hourly and Atlassian spreads those wake-ups across the hour, so an occurrence due at 03:00 typically appears a few minutes past the hour rather than exactly on it.
When the last one is still open
This is the setting most recurring-task tools do not have, and it is per template.
| Policy | What happens if the previous issue is still open |
|---|---|
| Always create | Creates it anyway. Right for reports — not having written last week's is no reason to skip this week's. |
| Skip | Creates nothing and records why. The series keeps its own rhythm and the next occurrence is unaffected. |
| Wait for it to close | Holds the occurrence and creates it the moment the previous issue closes, re-checking hourly. If another occurrence falls due while one is already held, the new one is folded into it rather than queued behind it — a queue of held occurrences is exactly the pile-up you were avoiding. Held occurrences are dropped after 30 days. |
Run history
Every template keeps its last 20 runs, newest first: what was created, or why nothing was.
| Result | Meaning |
|---|---|
| Created | The issue key is shown and links to the issue. |
| Skipped | Which issue was still open, and the status it was in. |
| Waiting | Held under the wait for it to close policy. One row per held occurrence, not one per hourly re-check. |
| Failed | Something in Jira rejected the issue — a deleted issue type, for instance. The row has a Retry button, and the template keeps its own schedule regardless. |
Runs also carry warnings when Recur had to degrade something rather than fail: a component that no longer exists, a priority removed from the scheme, a deactivated assignee. The issue is still created; the missing field is dropped and the reason is recorded.
A recurring-task app that quietly creates nothing is the most confusing thing it can do, so “why not” is a first-class result here rather than a silent absence.
Administration
Project administrators create, edit, pause and delete templates in their own projects. Permission is checked as the calling user on every mutating action, so it reflects real Jira access rather than what the UI happens to show.
Jira administrators additionally get a site-wide page listing every template across every project, so a template does not become invisible when the project lead who created it leaves.
Issues are created with the app's own authorisation, which is why management is restricted to project administrators.
If a project is archived or deleted, the templates in it disable themselves and record the reason instead of failing every hour.
Permissions the app requests
| Scope | What it is for |
|---|---|
read:jira-work | Read projects, issue types and components; read issue status for the check on whether the last one is still open; verify the caller's administrator permissions |
write:jira-work | Create the recurring issues |
read:jira-user | The assignee picker, and the check on whether a person is still active |
storage:app | Store templates, run history and scheduler state in Atlassian-hosted app storage |
There is no external permission, so Forge blocks outbound calls at the
platform level. See the privacy policy for what is stored and
where.
Data, privacy and licensing
Everything lives in Forge storage inside your own Atlassian tenant: template configuration, run history, the due index, and the account ids of whoever created a template or is picked as an assignee. No issue content, email addresses, IP addresses or analytics. Uninstalling the app removes all of it. Full text: privacy policy.
Licensing is handled by Atlassian. Sites with 10 users or fewer are free with every feature; paid tiers start above that.
Not in this release
Recur deliberately does not try to replace Automation for Jira. It does one thing: it creates issues on a schedule and tells you exactly what it did.
- Rich text (ADF) editing for the description — it is plain text today, converted to ADF at creation
- Recurring sub-tasks
- Exporting and importing templates
- Cloning an existing issue with all of its fields
- Cross-project bulk cloning
- Free-form cron expressions
- Jira Service Management-specific fields
Support
Questions, bug reports and feature requests: keelapps.atlassian.net/helpcenter/support/, or support@keelapps.atlassian.net.
Security issues: report privately, not in a public channel.
Privacy or data requests: use the address on the privacy policy.