Scheduling
Reports that are published with source code can be scheduled to execute by Posit Connect.
For more information on publishing, see:
- Publish Source Code - for R Markdown reports
- Quarto - for Quarto content
- Scripts - for rendered script files
Administrators can view a list of all scheduled content on a Connect server in the Dashboard web interface, under the System > Scheduled Content tab.
Content can either be executed manually or on a schedule. In order to schedule your content, you must publish the source code.
Similarly, applications and interactive documents such as Shiny R Markdown, Shiny with Quarto, and Voila for Jupyter notebooks cannot be scheduled. These interactive frameworks show the latest data each time they are refreshed.
In other cases the Schedule panel provides options to schedule your content for execution on Connect.
Render new versions when they are deployed
Connect renders content such as an R Markdown report or a Jupyter notebook each time you deploy it. The output matches the code as soon as the deployment finishes. This setting is on by default, and it appears only for content that Connect renders.
Turn off Render new versions when they are deployed to deploy the code without running it. Viewers keep the output they already have until the next render. That render runs on the schedule, or when someone clicks Refresh.
Turn the setting off when the output belongs on a schedule rather than on every deployment. It also helps for content that is expensive to run, because a deployment no longer starts a render.
With the setting off, a schedule or a refresh is the only thing that moves the output forward. Content without a schedule keeps its output until someone refreshes it.
Find which version produced the output
Once a deployment stops rendering, the active code and the output that viewers see can differ. Connect reports that difference in three places:
- The content page names the bundle the output came from, and the bundle the next render uses.
- The Source tab names the bundle the current output came from, below the active bundle.
- The rendering history labels each rendering with the bundle that produced it.
A render always runs the active bundle, whether a schedule, the Refresh button, or the API starts it. When that render finishes, the output matches the active code again, and the content page and Source tab stop reporting a difference.
Content that has never been rendered
Content can have deployed code and no output at all, either because no deployment rendered it or because the first render failed. A browser that opens this content gets a page explaining that the content has no output. Viewers who can reach the content page also get a link to it, where they can start a render. Other clients, such as scripts and monitoring checks, receive a 404 response, because the URL has no output to return.
Parameterized content
The setting applies to the whole content item rather than to the variant selected below it, so it reads the same on every variant. A deployment renders only the default variant. Saved variants keep the output they have until each one renders on its own schedule or someone refreshes it.
Next and most recent runs
After you save a schedule, the top of the Schedule panel reports when the next render happens, in the schedule’s timezone, and how the most recent one finished. The panel identifies a render that is starting or in progress. Click View logs to open the output of that render. To see the exact time a render started or finished, hold the pointer over the time beside its status.
The panel refreshes while it is open, so the next run time stays accurate without reloading the page. While you have unsaved changes, the times describe the schedule you last saved.
Date and time
The start Date and Time defaults to the current user’s date, time, and timezone. If applicable, report execution for daylight savings time (DST) is based on the timezone selected.
If you choose a start date and time in the past, execution begins at the first future execution that satisfies Schedule Type, measured from the time that changes are saved.
The simplest way to schedule report execution for multiple times a day is to set up an interval defined in hours. A schedule defined in minutes or hours will not be affected by daylight savings time.
Schedule type
The Schedule Type and related fields determine how frequently the content is executed by Connect. Using the Date and Time above as an anchor, Schedule Type defines the time interval between executions.
For monthly schedules that run on a given day of the month, reports execute on that exact day. If a month does not include that day, it will be skipped. For example, if today’s date is January 15th, and the schedule is set to run monthly on the 31st, then the next two executions will be January 31st and March 31st because February does not have 31 days.
The following interval configurations are all supported:
- defined in minutes
- e.g.: “every 15 minutes”
- e.g.: “every 90 minutes”
- defined in hours
- e.g.: “every 3 hours”
- e.g.: “every 25 hours”
- defined in days
- e.g.: “every 2 days”
- e.g.: “every 40 days”
- every weekday
- e.g.: “Monday, Tuesday, Wednesday, Thursday, Friday”
- defined in weeks (on select days of the week)
- e.g.: “every week on Tuesday and Thursday”
- e.g.: “every 8 weeks beginning on a designated date”
- semi-monthly (1st and 15th)
- e.g.: “on the 1st and 15th of every month”
- semi-monthly (14th and last)
- e.g.: “on the 14th and last day of every month”
- monthly on a given day of the month
- e.g.: “every 2 months on the 3rd”
- e.g.: “every 8 months on the 30th”
- monthly on a week / day
- e.g.: “every 3 months on the 3rd Tuesday of the month”
- e.g.: “every 9 months on the 1st Saturday of the month”
- defined in years
- e.g.: “every 2 years”
- e.g.: “every 8 years”
Schedule end
You can choose to have your content run on this schedule indefinitely, or configure it to end at a set date and time. By default, the Ends Never radio button is selected. To configure an end date for your scheduled content, select Ends On and use the calendar and time picker.
Send email
This section of the schedule configuration determines if and where emails are delivered after execution. If checked, the owner of the content will always be notified unless they unsubscribe. Content output can be sent to:
- all collaborators
- all viewers
- server broadcast (may be unavailable in your configuration)
- named additional recipients
By default, Connect generates a standard subject line and email body. For R Markdown reports, the rendered output is automatically attached to the email. Quarto documents require email customization to include attachments. For more information, see R Markdown email customization or Quarto email customization.
You cannot schedule content to be sent to additional recipients that are not Connect users.
If you are having difficulty sending emails, contact your Posit Connect administrator.
Failure notifications
Posit Connect sends an email notification when there is a report rendering error event. A rendering error may occur any time the content runs. Similarly, email notifications are sent when a report environment fails to restore. By default, Connect sends the notification email to the content owner and all named collaborators. A Connect administrator can change this behavior so that only content owners receive notification emails with the Applications.NotificationsToOwnerOnly configuration setting. This setting also controls whether collaborators receive application error notifications and content access request emails.
The failure notification includes a link to the log for the failed run. If email is not configured on your Connect server, Connect records the error in the logs but sends no notification. Contact your Connect administrator if you expect notifications and do not receive them.
Server broadcast
If your Posit Connect server administrator has enabled Connect with the Server.MailAll configuration setting, you may be able to send email as a Server Broadcast. This means that everyone who has logged in to Connect before receives a copy of your scheduled report.
If there are groups added as viewers or collaborators to the content, the user members will not be emailed in a server broadcast if they have never logged in.
Failed renders
A render can fail for either a manual or a scheduled execution. In both cases, Connect discards the failed output rather than publishing it. After a failed render:
- The content owner and collaborators receive a failure notification, if email is configured.
- Connect does not update the report history, because it records only successful renders.
- The most recent successful render remains the version Connect serves at the content URL. Viewers continue to see that output, and Connect does not show them an error.
- Connect does not send the scheduled output email. Connect sends content output only after a successful render.
- Connect retains the render log for the failed attempt in the logs viewer.
If the initial render of a new bundle fails during deployment, Connect activates the previous bundle again. For more information, see Failed deployments.
Connect does not automatically retry a failed render. A failure also does not shift the schedule. Connect determines the next run from the schedule you configured, so the report runs again at its next scheduled time.
Because a failed render leaves the previously rendered output in place, content can appear current when it is out of date. If you suspect that a report is stale, check the most recent render date in the history panel and review the logs for the most recent run.
If renders fail repeatedly, the source might contain an error, or it might not run in the deployed environment. Resolve the problem in the source and publish the content again.
Schedule concurrency
By default, Connect permits up to 10 scheduled reports to run concurrently in Local Execution mode, and up to 20 in Off-Host Execution mode. This can cause scheduled reports to run later than expected when:
- Long-running reports overlap with other reports’ scheduled execution times.
- Multiple reports are scheduled to run at the same time.
If your scheduled reports are consistently delayed, ask your Connect administrator to increase the Applications.ScheduleConcurrency value to allow more reports to execute in parallel.