Access to raw application logs in RStudio Connect



It’s quite common to receive bug reports for our Shiny applications that require me to go look at the logs to really understand what happened. I know that it’s possible to view application logs in Rstudio Connect through the web interface, though I notice that they are truncated to only the last few hundred lines or so.

I’m wondering (a) if it is possible to access the complete log for a session, and (b) if the logs are actually stored on the server somewhere that I could access them.

More broadly, has anyone developed a system for auditing application logs effectively that they’d like to share?


The logs should be located in /var/lib/rstudio-connect/jobs (unless you’ve specified a different DataDir in the [Server] section of your Config file).

However, you can also download the logs for a specific process through the Connect Dashboard. Are you saying that even when you download a process’s logs, they are truncated?


As far as we have looked it seems that the logs will always be truncated to 10KB size. But as @dwh said you can download them from Dashboard in UI and they will be identical to the ones that are stored in server’s backend.


Unfortunately, the logs that I download from the Dashboard UI are also truncated to 11KB or so.

However, I’ve been able to access the full log files on the server side (in rstudio-connect/jobs/<app>/<session>/job.stderr) without issue.


I can confirm that RStudio Connect is truncating process logs when showing/downloading logs in the RStudio Connect dashboard. The full logs for both stdout and stderr are retained on-disk without truncation.

Log truncation is helpful when using the RStudio Connect dashboard. Unfortunately, we are also performing the same truncation when the log is downloaded.

We seek to 10k bytes from the end-of-log for both stdout and stderr (tracked separately) and then seek for the first line-start from that point. Those two streams are then interleaved. We may trim one of the two streams if they are from very different points in time (stdout data appearing before 100k of stderr data, for example).

If stdout and stderr fit into 10k bytes each, the full log content is returned.

We will address this problem in an upcoming release.