The debugger is a good way to understand why the current situation leads to an issue. Once you have a way to reproduce an issue, you can use this tool. In some cases, however, issues will be in the past. If you have a user that reports an issue with a payment, an invoice that wasn't been sent, etc. the first step is to check what happened in the past. This can help you identify a pattern, which can lead to finding a way to reproduce (and then using the debugger).
That is what the Server Logs feature is for. It lets you see past executions of workflow runs that happened on the server (see this for more details about the client-server distinction). You can access the server logs in the Logs Tab.
Note that server logs depend on the version of your app, so you should make sure you are focusing on the one the issue was reported in (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.
- 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 result 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.