For Jira administrators · Updated 12 August 2026
This page explains what every value on the app's admin screen means, and what to do when something looks wrong. You can reach the screen at Settings → Apps → Overdue Digest in your Jira site.
Once a week, each person who has work in one of two bands receives a single email listing it:
work that is 8 or more days overdue, and work that is due in 3 to 7 days.
Both the assignee and the reporter of a work item receive it — and if a work item has no assignee, its
reporter still receives it, with the row marked Unassigned. Jira sends the message; the
app has no mail server of its own.
Those day counts are measured in UTC, not in your local timezone. The app runs on Atlassian's scheduler, which has no timezone of its own, so it counts whole UTC days between today and the due date. If your team is several hours ahead of or behind UTC, a work item sitting exactly on a boundary — due in exactly 3 days, or exactly 8 days overdue — can land on the other side of that boundary from what your local calendar shows. This is expected, not a fault.
The app checks once a day and sends at most one digest per person per week. A fuller description of what it reads and sends is in the Privacy and Security Policy.
The badge at the top of the screen is the short answer to "is this working?" It is the only line you need to read when nothing is wrong.
| Badge | What it means |
|---|---|
Delivering |
Normal. Runs are completing, and the date of the most recent completed run is shown underneath. |
Waiting for first run |
The app has been installed but has not completed a run yet. The first run usually happens within a day of installing. |
Paused |
Weekly delivery is switched off. No digests are being sent. This is a setting, not a fault. |
Not delivering |
Something is wrong with the schedule. A message below the badge says which of the two schedule failures it is — the second and third rows in section 5. |
Status unknown |
The app could not work out its own state. Reload the page once. If it
still says this, it will not clear on its own — please get in touch. This is not the same as losing the connection: if the screen simply cannot reach the app, it says Could not load status. Please reload the page. instead, and that one
usually does clear on a reload. |
Day to day, you do not need to read these. The badge above already answers "is it working?". These two dates are what you look at when the answer is no.
They look similar and are not. The difference between them is the whole point of the section.
| Value | What it means |
|---|---|
Last started |
The date a scheduled run most recently began. |
Last completed |
The date a scheduled run most recently finished. |
In normal operation both dates show today or yesterday, and both move forward every day. If they do, there is nothing for you to do.
When they stop, the gap between them tells you which half has broken:
A dash (—) in either field means the app has not recorded that value yet.
The same thing in either case: get in touch, and quote both dates. Neither fault can be fixed from this screen, and neither is caused by anything in your Jira configuration — so there is no setting for you to go hunting for.
The screen shows two dates rather than one not so that you can diagnose it, but so that when you tell us, we already know which half failed. That is usually the difference between a fix that takes minutes and one that takes days.
The heading above these four numbers reads Week of … to … (UTC). The app's week runs on
UTC, so it may not line up with the calendar week in your own timezone.
| Value | What it means |
|---|---|
Recipients identified |
How many people had at least one matching work item this week. |
Recipients processed |
How many of them the app has already handled this week. A recipient is recorded before the email is sent, so this number also counts the failures below. |
Failed |
How many recipients Jira did not accept the request for. This can happen when the app cannot browse the project a work item belongs to, or when Jira was temporarily unavailable. Unlike the schedule faults in section 5, this one may be something you can act on — see below. |
Still pending |
How many identified recipients have not been handled yet. This is normally 0 by
the end of the week. |
Because a recipient is counted as processed before the send is attempted,
processed includes failed. They are not two separate groups.
The four numbers only mean something as a set. These are the combinations you are likely to see:
| identified | processed | failed | pending | What it says |
|---|---|---|---|---|
| 12 | 12 | 0 | 0 | Everyone got their digest. This is the normal end state for a week. |
| 12 | 12 | 2 | 0 | 10 people got it, 2 did not. Everyone has been handled, but two sends were refused. Worth telling us about if the same number comes back week after week. |
| 12 | 5 | 0 | 7 | Still working through the list. Normal mid-week: the app spreads the work across daily runs, and the remaining 7 are picked up by the next one. |
| 12 | 12 | 12 | 0 | Nobody got it. Everyone was attempted and every send was refused — usually a permissions problem rather than a fault in the schedule. Please get in touch. |
| 0 | 0 | 0 | 0 | Nothing matched this week. No work item fell into either band. This is a good sign, not a fault. |
Two rules make the rest readable: identified always equals
processed + pending, and failed is a subset of
processed — never added on top of it.
A one-off failure is usually Jira being briefly unavailable, and it clears by itself. A number that comes back week after week is worth looking into, and this is the one figure on the screen you may be able to act on yourself: check that the app is allowed to browse the projects those work items live in. The app reads and sends under its own identity and is subject to your permission schemes like any other user, so a project it cannot browse is a project it cannot email about.
If the permissions look right and the number persists, please get in touch — at that point it is ours to investigate.
The Privacy and Security
Policy describes the same four counters from the storage side, where they are called
targeted, recorded, failed and pending. They are the same four
numbers as identified, processed, Failed and
Still pending here — the policy names what is stored, this page names what is shown.
When the app detects a problem with its own schedule it shows a message above these values. There
are three, and they mean different things. The first one is not a fault — it carries
the Waiting for first run badge. The other two carry Not delivering.
| Message | What it means |
|---|---|
No scheduled run has been recorded yet |
The app has never run. This is expected just after installing. If the app was installed more than a day ago, please get in touch. |
Scheduled runs have stopped |
Runs are not being triggered any more — the last one began about two days ago or longer. While this continues, weekly digests are not being sent. |
Scheduled runs are not completing |
Runs begin but do not finish. Some weekly digests may not have been sent. If a run is still in progress the message clears on its own. |
None of these three schedule messages can be fixed from the admin screen,
and none of them are caused by your Jira configuration — they are about whether the app's scheduled run
is firing at all. (The Failed counter in section 4 is a different matter, and that one may
be actionable on your side.) Please get in touch at
contact@myriastrastudio.com and we will look into it.
If you believe the problem is urgent, please say so in the subject line.
The Weekly delivery switch stops all digests for the whole site. It takes effect from the
next scheduled run; a run already in progress finishes.
While delivery is off, the badge reads Paused and no email is sent to anyone. Turning it
back on resumes delivery from the next scheduled run. Anyone who has not yet received their digest
for the current week will receive it on that run; digests missed in earlier weeks are not sent
afterwards.
While delivery is off, Last completed stops moving, because a run that is
switched off does not complete. Last started keeps moving daily, so you can still see that
the schedule itself is alive. For about two days after you switch delivery back on, the app
deliberately does not show the Scheduled runs are not completing message, because the gap
your own pause left behind would otherwise be reported as a fault.
Uninstalling the app removes its stored settings. If you uninstall and later reinstall, weekly delivery starts switched on again — the off switch does not survive an uninstall, so it is worth checking this screen after a reinstall if you had it paused on purpose.
Individual recipients cannot opt out on their own. If someone does not want the email, the switch above is currently the only control, and it applies to everyone.
Email contact@myriastrastudio.com about anything — a fault, a question, a request, or something this page failed to explain.
If you are writing about delivery not working, it helps to include the badge text and the two dates from the Delivery section. Those three values tell us which half of the schedule is failing, which is usually most of the diagnosis.