Troubleshooting

Build errors on deployment

You may see an error when you deploy an application that is working properly on your local machine, indicating that a package has failed to be built. For example:

Building R package: xml2 (0.1.2) /mnt/packages/build /mnt
* installing to library '/usr/local/lib/R/site-library'
* installing *source* package 'xml2' ...
** package 'xml2' successfully unpacked and MD5 sums checked
Found pkg-config cflags and libs!
Using PKG_CFLAGS=-I/usr/include/libxml2
Using PKG_LIBS=-L/usr/lib/x86_64-linux-gnu -lxml2
** libs
Error: package 'Rcpp' 0.11.3 was found, but >= 0.11.4.6 is required by 'xml2'
* removing '/usr/local/lib/R/site-library/xml2'

This error message indicates that the version of Rcpp (0.11.3) used by the xml2 package in your application requires a later version (>= 0.11.4.6). Recall that shinyapps.io recreates your environment on the server side, and compiles the same versions of the packages that you are using when you run on your machine. Packages installed on local desktops are typically downloaded in pre-compiled binary form, and may work properly with older packages they rely on (in this case Rcpp). However, if you tried to build all these packages from scratch, the package would fail because it requires a later version of the package.

To resolve this class of issues, you will need to upgrade the packages to later versions. In this case, this will require running install.packages("Rcpp") locally, running your app to verify that it works properly, and redeploying the app to shinyapps.io.

If this does not resolve your issue, drop us a line in the shinyapps.io Community, and we will be happy to help.

Password reset flow failing

There have been reported cases in which a reset password email will not trigger the reset of the password when clicked within the email UI. We have not yet pinpointed the underlying cause (we suspect interference from a class of virus protection software), but the workaround is to copy the URL from the email into a fresh web browser and go to the URL directly.

Grey screen

By default, an application will close an idle connection after 15 minutes of inactivity. This means if you open an application and do not interact with it for 15 minutes, you will see a disconnect (grey screen). With the Basic plan and above, you can configure your application to fine-tune its performance, including the idle connection timeout value. Instructions for manipulating these controls are in our Scaling and Performance Tuning article.

“Disconnected from server” messages

Whenever an R process dies or is shut down, shinyapps.io will display a “Disconnected from server” message in the browser. If you see this message frequently or unexpectedly, you can check your application logs to see if there are any errors. You can do that by running rsconnect::showLogs(), or by visiting the shinyapps.io dashboard and looking at the logs in your Application view.

Even if there is no error in the application log, the problem may still lie within your code. There are many resources available online to assist you in debugging and optimizing your app, including our Debugging Shiny Applications article, and the shinyapps.io Community.

Be aware that your app may run well locally, but fail on shinyapps.io. This could happen for a variety of reasons, including but not limited to:

  • Your application may be dependent on code or environment variables that are only present in your local environment. Make sure your application is defining any environment variables that need to be set, your application is properly sourcing any external code, and your application bundle includes all necessary files.
  • Your application may be dependent on packages that are installed and loaded in your environment, but aren’t included as library() calls in your application. Make sure that you have explicit library() calls in your application for all packages required for your application.
  • Using absolute file paths instead of relative paths. For example, the following two examples will fail:
    • Windows: read.csv("C:\myapplication\data\myfile.csv")
    • Linux or Mac: read.csv("~/myapplication/data/myfile.csv") Instead, your application should reference the data file by a path relative to the application, e.g., read.csv("data/myfile.csv"). See the section on Storage for more information.
  • Attempting to change the working directory. This is a corollary to the previous item. The working directory is the directory where your ui.R and server.R files reside. If you need to reach files in a subdirectory, you should use relative paths rather than changing the working directory. For example, the following two examples will fail:
    • Windows: setwd("C:\myapplication\data")
    • Linux or Mac: setwd("~/myapplication/data")
  • Attempting to access resources that are not reachable from shinyapps.io (for example, a database behind your organization’s firewall)
  • Use of packages that require Windows (shinyapps.io runs on Linux)
  • Use of packages that require access to the display (e.g., packages that require Tcl/Tk)
  • Your application may be failing when it comes under the load of several users. This could also happen for a number of reasons, including:
    • Forgetting to close each database connection after loading in data (the connection limit may be hit)
    • Making multiple long-running calls to a public API (the API request limit may be hit)
    • Sub-optimal application instance or worker provisioning (see the Performance section below)

Performance

For information about Performance issues, we recommend reading our article on Performance and Tuning.

You should consider tuning your applications if:

  • Your application has several slow requests, and you have enough concurrent usage that users’ expectations for responsiveness are not being met. For example, if your response time for some key calculation is one second and you would like to make sure that the average response time for your application is less than two seconds, you should not have more than two concurrent requests per worker.
    • Possible Diagnosis: The application performance might be due to R’s single-threaded nature. Spreading the load across additional workers should alleviate the issue.
    • Remedy: Consider lowering the maximum number of connections per worker, and possibly increasing the maximum number of workers. Also consider adding Application Instances and aggressively scaling them by tweaking the Instance Load Factor to a lower percentage.
  • You see sudden large spikes of traffic that see poor performance, even though you have configured multiple Application Instances. However, additional new users have good performance.
    • Possible Diagnosis: The number of workers within the first container are insufficient for the initial spike of traffic. When the additional containers are started, new users are routed to the new Application Instance.
    • Remedy: Decrease the Instance Load Factor, which will aggressively start up additional Application Instances and spread the load.
  • Your application suddenly goes grey and you see in your logs that the application was “killed”.
    • Possible Diagnosis: Each Application Instance has a size which corresponds to the amount of memory (RAM) that is allocated to it. If the amount of memory allocated to this application is exceeded, then the Application Instance could be shut down by shinyapps.io.
    • Remedy: There are two possible solutions:
      • Increase the size of the Application Instance.
      • Decrease the number of workers per Application Instance. Since each worker takes up additional RAM, you may find that lowering the “Max worker processes” to two or one would help keep each Application Instance’s memory usage down.
  • An application does not fit in memory, even with the largest Application Instance size selected
    • Possible Diagnosis: If the application loads correctly with one or two users interacting with it, then it is possible that your data set sizes on a per-worker basis are too large.
    • Remedy: Decrease the number of workers per Application Instance.
  • Your application stops accepting additional users beyond 150 connections.
    • Possible Diagnosis: It is likely that you have reached the limit on the number of connections that can be served by the default settings in an Application Instance.
    • Remedy: A few things to try would be:
      • Increase the allowed connections per worker by changing the Connections setting for the application.
      • Increase the number of workers per Application Instance.
      • Add additional Application Instances.
  • An application that has a significant initialization time (loading lots of data, or talking to third-party web services) sometimes does not load.
    • Possible diagnosis: shinyapps.io has an “Startup Timeout” which will stop an application if it is not responsive within that period of time at startup.
    • Remedy: Increase the timeout on the Application Settings page.