Digest for Jira — documentation
Digest folds a period's worth of Jira changes into one structured summary — issues created, status transitions, assignments to you, priority changes, comments that @mention you — delivered to an in-app inbox you read when you choose. It is not a notification rules engine: it does not filter, rewrite or intercept Jira's own notifications.
Digest is built on Atlassian Forge. This release requests read-only Jira scopes, and there are no external servers — no data leaves Atlassian's infrastructure, so there is nothing extra for a vendor security review to look at.
Getting started
- Open Apps → Digests in Jira.
- Create a subscription: a JQL query, a cadence — daily at a chosen time, or weekly on a chosen day — a time zone, and a grouping (by project, assignee or status).
- Hit Run now to queue the first digest instead of waiting for the schedule. It lands in the inbox on the same page within a minute or so — press Refresh there to see it.
- From then on, each period folds into one digest, normally delivered within an hour after it is due, never before.
Subscriptions are strictly personal. You create and manage your own; nobody else's subscriptions appear in your list, and yours appear in nobody else's.
What a subscription contains
| Field | Notes |
|---|---|
| JQL query | Anything you could run in the issue navigator. currentUser(), watchedIssues() and votedIssues() mean you. A digest runs while you are away, so a saved filter shared with nobody, and functions that answer for whoever is signed in such as issueHistory(), are refused with the reason when you test or save the query. A query Jira rejects or forbids pauses the subscription with Jira's own error message; a valid query that matches nothing is simply an empty period, so check it returns what you expect before saving. |
| Cadence | Daily at a chosen hour (on the hour, or at :15, :30 or :45), or weekly on a chosen day. |
| Time zone | Your browser's time zone to start with, or any IANA zone — type your city to find it. “Daily at 09:00” means your 09:00, not the server's. |
| Grouping | By project, assignee or status — how the digest arranges its entries. |
| Empty digests | Off by default. A period with no changes delivers nothing unless you tick Send even when nothing changed. |
What goes into a digest
Each run collects what changed in the window and classifies it:
- Issues created
- Status transitions
- Assignments to you
- Priority changes
- Comments that @mention you (a per-subscription checkbox)
- Reassignments to other people
- Any other update that matched your query, labelled simply Updated
An entry is an issue key, a truncated summary, the issue's status, assignee, project and type, and short change labels like Status: To Do → In Progress — never descriptions, comment bodies or rich text. That restraint is a privacy property as much as a layout one: see what the app stores.
When more than 50 issues changed in the window, the digest shows the 50 most notable and says so, with a deep link that opens the full result in the issue navigator, which counts only what you can see. The digest gives no total of its own: it was counted with the app's permissions, and that number could include issues you cannot open.
The inbox
Digests are delivered to the inbox under Apps → Digests: newest first, with unread counts, Refresh and mark all read. Nothing is emailed; you read the summary when you choose to.
The inbox keeps your 50 most recent digests across all of your subscriptions, oldest out first. Deleting a subscription deletes its digests.
Schedules and time zones
Every subscription picks one IANA time zone, and the cadence is evaluated in it. Two people in different time zones each asking for 09:00 get different instants, each of which is 09:00 local to them — on both sides of a daylight saving change.
A digest normally arrives within an hour after it is due, and never before. Digest wakes up hourly and Atlassian spreads those wake-ups across the hour, so a digest due at 09:00 appears somewhere in the following hour rather than exactly on it; if Atlassian skips a wake-up altogether, the next sweep picks the run up — it is never dropped.
Windows tile. A run's window opens at the previous successful run, not at “now minus 24 hours”, so a late run covers the gap instead of dropping it. The look-back is clamped to two nominal periods, so an outage cannot produce a three-month digest.
Who sees what
Scheduled runs have no user context, so digests are generated with the app's own permissions. When you open one, it is re-filtered against your own Jira permissions at that moment: anything you cannot see is stripped and replaced by a count (“Some issues are not shown … N issue(s) … have been hidden”), never the items themselves. For the same reason the inbox shows no issue counts: they were taken with the app's permissions. An opened digest counts only what you can see.
The check fails closed. If your access to an issue cannot be confirmed, the entry is treated as hidden rather than shown.
A digest is a stored copy of what a query once saw. Re-filtering at read time means losing access to a project also means losing access to its history in your digests — the copy never outlives the permission.
When something goes wrong
| Situation | Behaviour |
|---|---|
| Jira rejects the JQL, or forbids it | The subscription shows Needs attention and the inbox carries Jira's own error message. Editing the subscription clears the fault and resumes the schedule. |
| The owner's account is deactivated | Their subscriptions move to Disabled and stop running. |
| Rate limits or a Jira outage | Retried with backoff, then deferred to the next hour, up to three times. The window is left untouched, so the next successful run covers the same period and nothing is lost. |
| Nothing changed in the period | Nothing is delivered, and the site's empty periods suppressed counter goes up — silence is recorded, not accidental. |
Limits
| Limit | Value |
|---|---|
| Subscriptions per person | 1 on the free tier, 25 with a paid license. Nothing else is gated — every cadence and grouping is in the free tier. |
| Issues per digest | The 50 most notable, with the total matched and a deep link to all of them |
| @mention detection | Optional per subscription. When on, it scans the 25 most recently updated issues in the window, reading each one's 20 most recent comments. |
| Inbox depth | Your 50 most recent digests, oldest evicted first. |
| Empty periods | Not delivered, unless the subscription opts into empty digests. |
| Look-back window | At most two nominal periods, however late the run is. |
Administration
Site administrators get Settings → Apps → Digest for Jira: counters for subscriptions, runs, deliveries, suppressed empty periods and failures. This release has no site-level settings to change. Counters only — no queries, no names, no account ids, no issue data. What a person subscribes to is their business.
Permissions the app requests
| Scope | What it is for |
|---|---|
read:jira-work | Run each subscription's JQL, and read changelogs and comments to classify what changed in the window |
read:jira-user | Notice when a subscription owner's Atlassian account is deactivated |
storage:app | Store subscriptions, digests, the inbox and site counters in Atlassian-hosted app storage |
Every Jira scope is read-only: the app cannot create, edit or transition an issue,
and the install prompt says so. 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: subscription configuration, digest bodies — issue keys, truncated summaries, status, assignee, project, type and short change labels, never descriptions or comment text — the inbox, and site-level counters. No 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. One subscription is free forever, with every cadence and every grouping; a paid license raises the limit to 25 subscriptions per person. Sites with 10 users or fewer pay nothing at all.
Not in this release
Digest does one thing: it folds a period of changes into a summary and delivers it in-app, then tells you honestly when there was nothing to say.
- Delivery as a Jira notification — the channel exists in the codebase but is compiled out of this release, because it needs a write scope and 1.0 keeps its install prompt read-only. A later version may ship it; delivery would still be by Atlassian's own notification service.
- Email sent by us — never in this release. There is no external email provider, and adding one would cost the Runs on Atlassian badge, so it is not on the near-term roadmap.
- Filtering, rewriting or intercepting Jira's own notifications
- Slack or Teams delivery
- Saved filters as a subscription source — a subscription is JQL; a filter can be named in it only if it is shared, not private to you
- AI-written summaries — a digest lists what changed; it does not paraphrase it
Support
Questions, bug reports and feature requests: keelapps.atlassian.net/helpcenter/support/.
Security issues: report privately, not in a public channel.
Privacy or data requests: use the address on the privacy policy.