There are two sets of log files that we can use to troubleshoot Microsoft Teams issues.
Debug Logs On Windows, these are accessed by holding CTRL + ALT + SHIFT + 1 … on OSX holding Option + Command + Shift + 1 — both the desktop and web client will download three files. In the web client, you’ve got to tell it to save each file individually. The desktop client automatically stashes the files in your downloads folder (sorry, OSX folks, not a clue where your files are!).
Bootstrap log: Teams desktop also has bootstrap logs at %appdata%\Microsoft\Teams\logs.txt This file is generally useful for launch failures, authentication failures, and issues where the app is restarting. Once Teams is started, only background authentication ‘stuff’ is logged here.
If you’re inclined to read them, the debug client log is JSON formatted text followed by lines with timestamp, message level, and the message. War (Warning), Err (Error), Inf (Informational) messages appear in the log. When my Internet connection goes flaky, I get “War” messages with timeouts. But I’ve also seen really strange errors about the back-end Skype call not being found (AFAIK, Skype and Teams share a back-end calling infrastructure. The Skype back-end was upgraded for the Teams launch, but it’s a shared resource).
I pull the log file into Excel and split it into columns with the timestamp, severity, and log data. You can use
to convert an ISO8601 timestamp into a value on which Excel can perform calculations. You can also just reformat it by replacing ‘T’ with a space and removing the ‘Z’
For some activities, you can isolate the end-to-end transaction. This means you can also calculate how long the transaction took. At-mentions are great because they’ve got an obvious start (search text entered … length 0 means just the @ symbol was used. You’ll see different lengths depending on what the user actually types) and an obvious end (dropdown is shown for X search results). There’s also a single remote call (calling atMentionsService.SearchForUserPrifileInChannel) and response (scope.processSearchResults) where you can determine delay introduced outside the local computer.
When performing calculations in Excel with DateTime objects, the result is in unit days. To display the results in seconds, multiply this by 86400 (number of seconds in a day, which anyone who ever administered Bind zone files will be able to tell you off the top of their head … otherwise 24 * 60 * 60)
In the at-mention above, it took a little over half a second to complete and all of that time was the network call.