Using Server Logs
Last updated
Was this helpful?
Last updated
Was this helpful?
While the Debugger lets you to test and debug the current situation, server logs enable you to explore issues in the past. That is what the Server Logs feature is for. It lets you see past executions of workflow runs that happened on the server.
The Server Logs section in the Logs tab allows searches of the log of server-side actions, such as send email or change data, executed when users interacted with the app. Search for a particular user by email or ID, within certain dates, or specific keywords.
Note that server logs depend on the version of your app, so you should make sure you are focusing on the version where the issue was reported (Live versus Development).
To search logs, you need to define the starting and the ending dates of the search. Searching logs can take some time, and the Editor will display entries as they arrive. When you already see some results and scroll down, the editor will fetch more entries (and the caption of the search button will change according to the situation).
If your app has a lot of traffic, you'll see a lot of logs. It is useful to narrow down the search by using some search criteria. The most common criteria you can use when searching for logs is picking the type of events you're interested in.
Workflow starts: shows all initiated workflows that run on the server, whether the condition is met and the workflow is executed, or not.
Passed events: shows all workflows that run after the condition evaluated to yes.
Non-passed events: shows all workflows that didn't run after the condition evaluated to no. This is useful as you try to debug something that didn't happen.
Actions: only shows actions, and not the events that led to this action's execution.
Errors: shows server-side errors that happened when executing a workflow. For instance, a credit card failure, or a send email failure. This will be especially useful to diagnose issues.
When you search for logs, if you have more information about the problematic workflows, you can narrow down the search even more by searching for specific users and terms. The first input lets you enter a user's email or a user's unique ID. When this is filled, the search will only return workflows started by this user.
The last box lets you type a string that you want to search for. If an action has a property that evaluated to some text and if you search for this text, the workflow will be retrieved. For instance, if you know an email was sent with the text 'Boston' in it, searching for 'Boston' will return the Send Email action.
Once results are retrieved, they will be displayed in the results area, starting from the more recent events. For each entry, you'll see the name of the action/event, the email and the ID of the user (if the user isn't signed up, the email will be 'Anonymous user'), and you'll see on the right part the evaluation of the properties for this action, event, or the error message if it's an error.
When you click on the action name (or of the event), you'll be taken to the place in the editor where this action is defined. A button 'zoom on this workflow' is a handy way to only show events, actions and errors for the current workflow. Seeing the succession of actions can be a good way to understand what happened and identify a pattern.
