When something did not happen

Almost every question about a schedule is answered by the rule's own History, which records every occurrence — including the ones that deliberately created nothing.

Read the run history first

Open History on any rule. Each past run carries:

• A status — succeeded, failed, skipped, or claimed (running right now).
• A trigger, when it was not the ordinary schedule — Run now for a manual run, recovered for one that stalled and was picked up again by the hourly sweeper.
• The scheduled time, in the rule's own time zone, which is what you set.
• The outcome — Created KAN-18 with KAN-19, KAN-20. Subtasks are named rather than counted, so a run that should have made three and made two says so.
• Any adjustment or warning, in the words below.

History pages 20 runs at a time, with Load older runs beneath.

What each explanation means

A run that did not happen exactly where the pattern put it says why:

• moved to month end The rule asked for a day that month does not have, and is set to use the last day instead.
• daylight saving skipped this time; ran when the clocks caught up The wall-clock time you chose did not exist that day. The run happened at the first valid instant after the gap rather than being lost.
• daylight saving repeated this time; ran once, at the first The wall-clock time happened twice that day. The run happened once, at the earlier of the two — never twice.
• not a working day; moved to the next one The rule is set to roll forward, and did.
• not a working day; moved back to the previous one The rule is set to roll backward, and did.
• no working day within a fortnight; ran on the day it fell on A roll searched 14 days and found nothing — usually a holiday list that closes for a month, or a working week with every day marked non-working. The run is reported rather than dropped.

When a run fails

Failures come in three kinds, and they are handled differently on purpose:

• Transient — a rate limit or a Jira outage. Retried automatically with backoff for up to 24 hours. Usually nothing to do.
• Configuration — the rule or the project is wrong. Retrying cannot help, so it is not retried; the What to do: line says what to change.
• Permanent — anything else. Recorded and visible rather than retried forever.

Jira's own message is always kept rather than paraphrased, because "Field customfield_10011 cannot be set. It is not on the appropriate screen" tells you exactly what to fix. The code beside it is stable and safe to quote in a support email:

Whichever kind it was, a failed run neither moves the schedule nor comes back later. The next run is fixed when the occurrence is claimed, before Jira is called, so a failure never delays or repeats it — once the cause is fixed the rule runs again at its usual time, and no backlog of retried tickets arrives with it. Nor is the failed occurrence re-created: a failed run is not a missed run, which is an occurrence that never ran at all. To fill the gap one left, use Run now, once per issue you want.

"Some rules are failing"

A health check runs once a day across every active rule in the project and writes one line under the rules table. It says three things the table cannot: how many of how many (the table shows one page; the audit counted them all), which ones by name, and since when — because three failures deep looks the same on day one and on day fourteen, and they are not the same problem.

Because it runs daily, the line can be up to a day old. A rule you have just fixed still carries its failing lozenge until the next check; its History is the live answer.

If the line is absent entirely, the audit has never run for this project — a project enrolled this morning has no audit yet. That is deliberately different from "checked, nothing wrong".

A rule did not create an issue

In roughly the order worth checking:

• It is not due yet. Runs happen within about 5 minutes of the time you chose. Check Next runs.
• The project was turned off. With the app off for a project, no rule in it runs and nothing appears in the project menu. Turn it back on — the rules are still there.
• The rule is paused, or has reached its end condition and shows completed.
• The previous issue is still open and the rule is set to wait for it. The history says which issue.
• It landed on a non-working day and the rule is set to skip. The history says so.
• A field left the create screen, or an assignee was deactivated. That is a FIELD_REJECTED or INVALID_REQUEST row in the history.
• The app is unlicensed. Scheduled runs stop while a licence is lapsed or a trial has ended. Missed runs are then handled by the rule's catch-up setting when it resumes.

Limits

There is no limit on the number of rules in a project.

Data and retention

Rules and project settings persist until you delete them. Run history records expire automatically 180 days after they are written — long enough to answer "what happened last quarter", and no longer. Uninstalling the app removes its stored data with the installation.

Everything is stored in Atlassian's own app storage inside your site. See the privacy policy.

Still stuck

Open the rule's History, and send us that row and the rule's name. That is usually enough to answer without needing access to your site.