Recur for Jira — documentation
Recur creates Jira issues on a schedule — weekly reports, monthly maintenance, quarterly access reviews, certificate renewals. Jira can repeat a work item up to monthly with Set to recur, or run an Automation rule you build for each task, and every run of either uses your Automation allowance. Recur works from templates, on any interval, at an hour in the time zone you picked, and decides per template what happens when the last one is still open.
Recur is built on Atlassian Forge. There are no external servers and no data leaves Atlassian's infrastructure, so a security review has no vendor infrastructure to assess — only the four scopes listed under Permissions.
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.
Project administrators (and Jira administrators) see the create and edit controls while the site has an active licence. 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}}— the number of issues this template has created, counting this one, so the first is 1. Skipped and failed runs do not count. 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 — any of them, not a short list. 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 an hour after it is due, and never before. Recur checks once an hour, at a minute Atlassian picks for each site, and creates every occurrence whose time has passed. On a site checked at :20, an occurrence due at 09:00 appears at 09:20, and one due at 09:45 appears at 10:20 — not at 09:20, before its time.
When the last one is still open
Each template picks one of three policies.
| 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 at the next hourly re-check after the previous issue closes. 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, which opens 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 for project administrators, and the template keeps its own schedule regardless. |
| Folded in | An occurrence fell due while an earlier one was already held under wait for it to close; it was merged into that one rather than queued behind it. |
| Gave up | A held occurrence waited 30 days for the previous issue to close and was dropped. |
| Paused | The template was paused when these occurrences fell due, so nothing was created. Written when it is resumed: one row that counts them, from the first to the last. |
| Missed | Recur found the occurrence more than 72 hours after it was due — the app was disabled for days, say — and moved on to the next run instead of filing an issue for a date long past. |
| Disabled | The template's project was archived or deleted; Recur disabled the template rather than failing every hour. |
| No licence | The site had no active subscription when the occurrence fell due, so nothing was created. |
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. Anyone who can browse a project can see its templates and their run history. Both are checked as the calling user on every action, so they reflect 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, components and priorities; 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 and its runtime state (next run, run count, last issue key, any held occurrence), run history, the due index, the scheduler cursor, per-run idempotency records, the cached licence state, and the account ids of whoever created a template or is picked as an assignee. No issue content, email addresses, IP addresses or analytics. When the app is uninstalled, Atlassian deletes it after 28 days. 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.