Understanding the Tempo Scheduler: Email Notifications | Knowledge Base Articles

This article is for Cloud and Data Center.

The Tempo Scheduler helps teams stay on track by automating email reminders based on time-tracking requirements. There are two primary types of notifications available:

1. Status Reminders

This email is sent to all active users within the scope of the scheduler. It provides a summary of their individual progress, comparing hours logged against the hours required for the period.

2. Late Reminders

This notification is specifically targeted at users who have not completed their required hours at the time the scheduler performs its check. The timing of this reminder depends on your specific Scheduler configuration.

Requirements for Receiving Notifications

To ensure users receive these automated emails, the following criteria must be met:

Workload Settings: Users must either have hours already logged for the period or be assigned to a Workload Scheme requiring more than zero hours.
Project Permissions: Users must have the "Work on Issues" permission for at least one active project.

⚠️ Important Configuration Note

For the Tempo Scheduler to successfully identify and message users, the "Work on Issues" permission must be granted to specific users, roles, or groups.

Note: Granting this permission to "Any logged-in user" is insufficient for the Scheduler's indexing; ensure your permission schemes explicitly define the target groups.

Managed Timesheet Closures and Grace Periods

When the "Make Scheduler Close" option is enabled, an additional configuration field appears in the Scheduler settings. This field defines the number of days after the period end date that the Scheduler will officially lock timesheets for editing.

Note: The "end date" is determined by the specific Period Type (e.g., Weekly, Bi-weekly, or Monthly) selected in your Scheduler configuration.

How to Edit After a Closure

Once the Scheduler has locked a period, there are two ways a user may still be able to add or modify worklogs:

Path 1: Approve Timesheets permission
Users with the Approve Timesheets Tempo Team permission can continue to create, update, or delete worklogs after the period is closed by the Scheduler — no grace period is required. This exemption applies automatically based on the permission, regardless of Scheduler settings.

Path 2: Grace Period (for users without that permission)

For users who do not hold the Approve Timesheets permission, all three of the following conditions must be met:
1. Grace Period: A Team Lead must grant the user a manual Grace Period.
2. Approval Status: The individual Timesheet must be in an editable state (it cannot be currently Submitted or Approved).
3. Period Management: The global period must still be marked as Open within Tempo's Period Management settings.
A Scheduler close is not a hard close. Only a manual close in Period Management locks a period for everyone. A Grace Period cannot override a Period Management close.

When selecting to Close 0 days after the end date, no Status reminders to late users can be sent. It is not possible to send late reminders before, or at the same time, as the status reminders.

Cloud:

Tempo Scheduler Configuration and Timing

To configure the Tempo Scheduler in Jira Cloud, navigate to Tempo > Settings > Scheduler Configuration.

1. Scheduler Frequency

The Scheduler can be configured to run on three different frequencies. The "End Date" for each period is determined by these settings:

Monthly: Aligns with the dates defined in your Period Configuration.
Weekly: Runs on a 7-day cycle.
Bi-weekly: Runs on a 14-day cycle.

2. Execution Timing

The Scheduler runs a background check once a day, just after midnight in your Jira site’s time zone. It evaluates the previous day, so a run at 00:00 on Oct 20 handles Oct 19.

On each run, the Scheduler closes through the latest period end that is on or before the run date minus the close days. If it is behind, one run closes every period that is due.

Scheduler Deadlines and Closure Logic

Type set to Monthly:

The End Date used by the Scheduler is defined by the final day of your Monthly Period Configuration. Understanding how the "Close" field interacts with this date is key to managing your timesheet lifecycle.

Timesheet Closure Limits

Maximum Closure Window: The “Close” field can be set for a maximum of 28 days after the period end date.
Execution Time: The close takes effect at the first daily run after the closure date ends, which is just after midnight in your Jira site’s time zone. Users can still log time on the closure date itself.

Notification Timing

When these options are enabled, the Scheduler automates email delivery at 11:59 PM UTC (23:59) based on the following logic. Reminders and closing may run at different times.

Status Reminder (All Users): Dispatched exactly on the Period End Date.
Late Reminders: The delivery date for this reminder shifts depending on your closure settings:
- If "Make Scheduler Close" is UNCHECKED: The reminder is sent X days after the Period End Date.
- If "Make Scheduler Close" is CHECKED: The reminder is sent X days before the scheduled closure date.

⚠️ Technical Note: The value for X must be greater than 0. While the interface may allow you to save the configuration with a zero or negative value without triggering an error message, the notification will not function as intended.

Scheduler Deadlines and Closure Logic

Type set to Weekly or Bi-Weekly:

When using the Weekly or Bi-weekly frequency, the End Date is defined by the specific weekday selected in the "Run scheduler on period end date" field.

⚠️ Configuration Note: Be aware that the Bi-weekly setting does not explicitly label which week of the cycle is the "active" one in the interface. This can occasionally cause confusion for users regarding exactly which week the Scheduler last executed.

Timesheet Closure and Deadlines

The Close field sets the closure date, which is the number of days after the period end date. The close takes effect at the first daily run after that date ends, just after midnight in your Jira site’s time zone. The maximum allowable window is limited by your selected frequency:

Weekly: Maximum of 7 days after the period end date.
Bi-weekly: Maximum of 14 days after the period end date.

How the close works

What gets locked: the close locks everything up to the period end, not only the closure date. A period ending Monday with 3 close days locks through that Monday, and the lock takes effect after the closure date on Thursday.
Bi-weekly cycle: a Bi-weekly cycle counts 14 days from the last closing date, and then lands on the weekday you selected.
Make Scheduler Close off: nothing closes, and the last closing date stays where it is.

Example: A Friday closure date for a site on Eastern time takes effect at about 00:00 on Saturday.

Notification Delivery Timing

Email notifications are dispatched at 11:59 PM UTC (23:59) according to the following rules. Reminders and closing may run at different times.

Status Reminder (All Users): Sent to the entire team exactly on the Period End Date.
Late Reminders: The delivery date for this reminder depends on your closure configuration:
- If "Make Scheduler Close" is UNCHECKED: The reminder is sent X days after the Period End Date.
- If "Make Scheduler Close" is CHECKED: The reminder is sent X days before the scheduled closure date.

Example: Weekly

Period end: Monday, May 1.
Closure date: Thursday, May 4 (end date + 3 days). Users can still log time for any date through May 4.
What gets locked: the first daily run after May 4 ends (just after midnight on Friday, May 5, in your Jira site’s time zone) locks everything through May 1.
Next period: the period ending Monday, May 8 has its closure date on Thursday, May 11 and locks through May 8 on the run just after midnight on Friday, May 12.

Example: Bi-weekly

The Bi-weekly cycle counts 14 days from the last closing date. For example, if the last close was through Monday, Apr 17:

Period end: Monday, May 1 (Apr 17 + 14 days).
Closure date: Thursday, May 4. The run just after midnight on Friday, May 5 locks everything through May 1.
Next period end: Monday, May 15, with its closure date on Thursday, May 18. It locks through May 15 on the run just after midnight on Friday, May 19.
Nothing closes in between: the Monday, May 8 week has no period end, so the runs from May 6 to May 18 don’t close anything.

Example: Switching from Weekly to Bi-weekly

Weekly, end day Monday, close 3 days after the end date:

Mon May 1: the weekly period ends.
Fri May 5: the run locks everything through May 1. The last closing date is now May 1.
Tue May 9: you switch to Bi-weekly with the same end day and close days. Save the change before the run on Fri May 12, which would otherwise lock through May 8. Bi-weekly counts 14 days from the last closing date, so Mon May 8 is no longer a period end and nothing closes for that week.
Mon May 15: the first Bi-weekly period end (May 1 + 14 days).
Fri May 19: the run locks everything through May 15, and then every 2 weeks.

Testing and Monitoring Limitations (Cloud)

Testing the Tempo Scheduler in a Cloud environment presents unique challenges, primarily due to the platform's automated nature.

Time Manipulation: Unlike local or server-hosted environments, Cloud users cannot manually adjust system time settings. This makes it difficult to "fast-forward" through a period to verify that closures or notifications trigger exactly as expected.
Visibility and Monitoring: Currently, there is no native monitoring dashboard within the Jira interface to track the Scheduler’s real-time status or execution history.

Because the Scheduler operates as a background service, validation typically requires waiting for the naturally occurring cycle to complete to confirm that all settings were applied correctly.

Data Center:

For those using Jira Data Center, the Tempo Scheduler is managed through the central administration panel. You can locate these settings by navigating to Jira Administration > Manage apps > Scheduler.

1. Scheduler Frequency

The Data Center version allows you to configure the Scheduler to run based on three distinct cycles:

Period: This follows the Default Period as defined in your global Tempo settings. To modify this, navigate to Tempo > Settings > Period Configuration.
Weekly: Runs on a standard 7-day cycle.
Bi-weekly: Runs on a 14-day cycle.

2. Execution Timing and Precision

Unlike the Cloud version, the Data Center Scheduler operates with higher frequency. The service performs a system check every 10 minutes to determine if any pending actions—such as dispatching notifications or closing timesheets—need to be executed.

Scheduler Deadlines and Closure Logic

Type set to Period

When the Scheduler is set to run by Period, the End Date is pulled directly from the final day of your Default Monthly Period, as defined in the Global Period Configuration.

Working-Day Based Closures

In the Data Center environment, the Close field is intelligently calculated based on your team's actual availability:

Calculation: The closure window can be set for a maximum of 5 working days.
Exclusions: The Scheduler automatically excludes Saturdays and Sundays, as well as any Holidays defined in your Default Holiday Scheme.
Execution Time: Timesheets are locked for editing at 11:59 PM (23:59) according to your Jira System Timezone.

Notification Delivery Timing

Email notifications are dispatched at 11:59 PM (23:59) Jira System Time based on the following logic:

Status Reminder (All Users): Dispatched to the entire team exactly on the Period End Date.
Late Reminders: These notifications are scheduled using an hourly offset:
- If "Make Scheduler Close" is UNCHECKED: The reminder is sent X hours after the Period End Date.
- If "Make Scheduler Close" is CHECKED: The reminder is sent X hours before the scheduled closure date (with a maximum allowable offset of 24 hours).

Scheduler Deadlines and Closure Logic

Type set to Weekly or Bi-Weekly

When configuring the Scheduler for a Weekly or Bi-weekly frequency, the End Date is determined by the specific weekday selected in the "Repeat on" setting.

⚠️ Configuration Note: For Bi-weekly cycles, the interface does not explicitly label which week of the rotation is currently active. To confirm if you are in the first or second week of the period, you must verify the "Next run" date displayed for the automated emails.

Timesheet Closure and Deadlines

The Close field determines when the Scheduler will officially lock timesheets for editing at 11:59 PM (23:59) in the Jira System Timezone.

Maximum Closure Window: For both Weekly and Bi-weekly frequencies, the closure can be set for a maximum of 5 days after the period end date.

Notification Delivery Timing

Email notifications are dispatched at 11:59 PM (23:59) Jira System Time according to the following rules:

Status Reminder (All Users): Sent to the entire team exactly on the Period End Date.
Late Reminders: These notifications utilize an hourly offset for precise delivery:
- If "Make Scheduler Close" is UNCHECKED: The reminder is sent X hours after the Period End Date.
- If "Make Scheduler Close" is CHECKED: The reminder is sent X hours before the scheduled closure date.

Testing and Monitoring (Data Center)

Testing the Tempo Scheduler in a Data Center environment is more flexible than in the Cloud, as you can simulate time-sensitive events by adjusting the system clock.

Simulating Scheduled Events

To "fast-forward" the Scheduler for testing purposes:

Modify Timezone: Adjust the timezone settings on your Jira server or local computer.
Restart Instance: It is highly recommended to restart your Jira instance after a timezone change to ensure the shift is fully recognized.
Verify System Time: Confirm the new setting by navigating to Jira Administration > System > System Info and checking the System Time field.

Monitoring Scheduler Execution

You can gain visibility into the Scheduler's background processes through the Jira internal job logs:

Navigate to Jira Administration > System > Scheduler Details.
Locate the job entry: CompatibilityPluginScheduler.JobRunnerKey.com.tempoplugin.scheduler.job.TempoJobRunner.
Select "Show more" to view the execution history, including when the job last ran and when the next check is scheduled.

Understanding Trigger Precision

Because the Scheduler checks for pending tasks every 10 minutes, there is a slight "offset" in execution. For example, if you have configured a Status Reminder for 23:59, the emails will be triggered by the first scheduler check that occurs after that timestamp has passed.

Advanced Troubleshooting: Enabling Debug Logs (Data Center)

If you require deeper insight into the Scheduler’s activities—such as exactly when it performs checks or dispatches emails—you can increase the logging verbosity.

Configuring Debug Logging

To capture detailed Scheduler events in your Jira logs:

Navigate to Jira Administration > System > Logging and Profiling.
Locate the Default Loggers section and click the "Configure" link.
In the Package Name field, enter: com.tempoplugin.scheduler
Set the Logging Level to DEBUG and click Add.

Best Practices for Log Management

Timed Execution: Because DEBUG logging generates a high volume of data and can quickly fill your log files, it is recommended to enable this setting shortly before the Scheduler is expected to run and disable it once the event has passed.
Persistence: Please note that this change is temporary. If the Jira service is restarted, the logging level will automatically revert to its default state.

Manual Database Updates for Local Testing (Data Center)

When testing on a localhost environment, you may need to manually adjust the "Time Registration closed until" date to bypass wait times or reset specific conditions. This can be accomplished by modifying the database directly.

Identifying the Closure Property

To locate the specific ID associated with the Scheduler's closure date, execute the following SQL query:

SELECT * from propertystring
WHERE id IN (
SELECT id
FROM propertyentry
WHERE property_key = 'Tempo.ClosedForRegistrationDate'
)

Updating the Closure Date

Once you have retrieved the correct id from the query above, you can update the value to a date that suits your testing scenario.

In the example below, we are updating the record (assuming an id of 52392) to set the closure for July 3rd, 2021.

⚠️ Important: While you can change the calendar date, you should not alter the timestamp format. The Scheduler is hardcoded to recognize closures at 23:59:59.

UPDATE propertystring
SET propertyvalue = '2021-07-03 23:59:59.000000'
WHERE id = 52392