Set them up at Settings → Marketplace apps → UndoTrail → Scheduled reports.
How delivery works
Each run attaches the report file to a work item you choose and adds a comment summarising it. Jira’s own notifications then tell everyone watching that work item, by whatever route they already get Jira notifications, email included. The email comes from Jira: the app itself sends nothing outside Atlassian.
A good target is a work item made for the purpose, such as OPS-12 Weekly audit trail, with the right people as watchers.
Creating a schedule
Fill in New scheduled report and press Create schedule.
| Field | Options |
|---|---|
| Name | Free text, up to 120 characters. Also used in the file name |
| Report | A project and a period, or A saved view |
| Project | For A project and a period: one project, or Every project you can see |
| Period | For A project and a period: Today, Yesterday, This week, Last week, This month, Last month, Last 7, 30 or 90 days |
| Saved view | For A saved view: any view you can open. The schedule copies the view’s whole query: scope, dates and refine filters |
| How often | Every day, Every week or Every month |
| Day of the week | For weekly schedules |
| Day of the month | For monthly schedules, 1 to 28, so every month has the day |
| At (UTC) | The hour, from 00:00 UTC to 23:00 UTC |
| Deliver to work item | A work item key, for example OPS-12 |
| File | CSV or Excel (XLSX) |
The line under the form shows the report the schedule will run, in words, before you save it.
A schedule copies the saved view’s query at the moment you create it. Changing the view afterwards does not change the schedule.
What each run delivers
| Part | Contents |
|---|---|
| The file | Named after the schedule and the run date, for example Weekly-status-audit-2026-09-28.csv. A run has no user and so no local time zone: the CSV carries the UTC date column but not the local-time and offset columns, and an Excel file shows its times in UTC. An Excel file also carries a Settings sheet naming the schedule, the run time, the JQL, the report and the projects it was limited to |
| The comment | The schedule’s name and timing, the period covered, the number of changes and work items, the five most recent changes (a comment change says only Comment deleted or Comment changed, never the comment’s text, which stays in the attached file), the file name, and a line saying whose schedule it is and which projects it was limited to |
The file and the comment are added by the app, so Jira shows the app as their author.
Permissions
A scheduled run happens with nobody at the keyboard, so it cannot run as a person. It runs as the app, which on its own could read every project. To keep a schedule from showing anyone more than its creator could see:
- When you save a schedule, the app asks Jira, as you, which projects you can browse and which issue security levels you can see work items at, and stores both on the schedule.
- A schedule that names a project you cannot browse is refused, and so is a delivery work item you cannot open.
- Every run is limited to those projects and security levels twice, once in the search and again on the finished rows.
- JQL whose brackets or quotes don’t pair up is refused when you save, and a run with such JQL reads nothing, because it could get past those limits.
- Before each run, the app checks that the schedule’s owner still has the History reports and Export permissions, and that the delivery work item is still in those projects and levels. If not, nothing is read or delivered, and the last-run outcome says Skipped and why. For a feature set to Jira admins only, the app goes by whether the owner was a Jira admin when they last saved the schedule, because it can’t ask Jira about someone who isn’t there.
- An owner who was a Jira admin when they last saved a schedule keeps both permissions for it. If you create a schedule and are later removed as a Jira admin, you keep getting its reports until it’s deleted. The same goes for an owner whose account is closed or deactivated: the schedule isn’t removed with the account, and keeps running while it passes the checks above. Admins see and delete every schedule under Settings → Marketplace apps → UndoTrail → Scheduled reports.
- The schedule list and every delivered comment say which projects the schedule is limited to.
Remember that the delivered file is readable by everyone who can see the delivery work item. Choose a work item whose audience should see the report.
Managing schedules
Each schedule in the list shows its timing, format and target, the report in words, the projects it is limited to, and the time and outcome of its last run.
| Button | Effect |
|---|---|
| Run now | Runs the schedule immediately and delivers it, without waiting for its hour. The outcome is shown straight away |
| Delete | Asks first (Yes, delete or Cancel), then removes the schedule. Nothing more is delivered for it |
People see the schedules they created. Jira administrators see them all, and can run or delete any of them.
Limitations
- Schedules are created and managed on the admin page.
- A schedule cannot be edited or paused from the page. Delete it and create a new one.
- Delivery is to a Jira work item. Email reaches people through Jira’s notifications to that item’s watchers, because the app has no permission to send anything outside Atlassian. The email carries the comment and a link; the file stays on the work item.
- The projects and security levels a schedule may cover are captured when it is saved. If its creator later loses access to a project or level, the schedule keeps covering it until it is replaced. A level the creator could see but had no work items at when they saved is left out until the schedule is replaced.
- A run reads up to the query’s Max work items and puts at most 50,000 rows in the file. When a run is cut short, the comment says so.
- Times are whole hours in UTC. A schedule runs once in its hour, not at an exact minute.
- A site can hold up to 100 schedules.
- Creating a schedule and Run now need an active subscription, and the History reports and Export permissions on the admin page. Every run, including one started with Run now, also needs the schedule’s owner to still have both permissions.
- While the subscription is inactive, due schedules are skipped: nothing is read or delivered, and each one’s last-run outcome says Skipped and why. They resume on their next due hour once the subscription is active again. A redeemed free access code counts as active.
- If a run fails, for example because the delivery work item was deleted, the reason is shown as the last-run outcome in the list. Nobody is notified.