Alerting
Using the Alerting Trigger you can set up workflows to process errors from your workflows. This enables you to monitor and take appropriate action to help you quickly rectify any problems which occur in your projects.
Using the Alerting Trigger you can set up workflows to process errors from your workflows.
This enables you to monitor and take appropriate action to help you quickly rectify any problems which occur in your projects.
Logging errors outside of Tray in some way is essential.
What service you choose for this logging process is up to you.
A few example options:
- Google Sheets (only suited to low throughput - be careful of API limits!)
- Airtable
- Database (SQL, Redshift, Snowflake etc.)
- Segment (more task-specific tracking and reporting options)
- Other task-specific apps you may have in your tech stack
Please see our Tray Academy course on error handling for an interactive lab and some guidance on how we handle errors at Tray!
Instance-level alerting
It is possible to set up an alerting workflow which will deal with errors for every single workflow in your Organization.
This can be done by a Workspace Admin by going to Account Settings > General > Alerting:
So by default any errors in your organization's workflows will go to this workflow.
Unless it is overridden by:
- Alerting workflows assigned to specific workflows
- Workflows in a personal workspace using a personal alerting workflow
Workflow-specific alerting
For each workflow it is possible to go into workflow settings and choose the alerting workflow that it will use:
Personal alerting
For all workflows in your personal workspace you can choose either an org-level alerting workflow or an alerting workflow from within your personal workspace:
This is done by going to your personal profile settings and setting the alerting workflow:
As with instance-level alerting, this can be overridden by the settings for individual workflows within your personal workspace.
Alerting payloads
An alerting payload contains the following basic info:
| Name | Description |
|---|---|
| workflow_uuid | The UUID of the workflow which sent the error |
| workflow_url | The URL of the workflow which sent the error |
| workflow_title | The title of the workflow which sent the error |
| step_name | The name of the specific step which was the cause of the error |
| step_log_url | This URL can be used to go directly to the point in the logs at which this error occurred |
| connector | The type of connector (and version) that caused the error |
| project_id | The unique identifier of the project the workflow belongs to |
| workspace_id | The unique identifier of the workspace where the error occurred |
| workspace_name | The name of the workspace where the error occurred |
| message | The internal Tray-generated error message |
| created | A timestamp of when the error occurred |
These are available as 'alerting variables' that can be made use of in any of your workflow steps
step_log_url is undoubtedly one of the most important here as it allows potentially quick troubleshooting and re-running of the source workflow:
Enhanced alerting payloads
When creating an alerting workflow it is often advisable to tick the 'Include raw response' option:
When enabled, this will include more detailed information as it will parse the specific response from the third-party API.
So for the above example of sending an unrecognized file id to Google Drive we could get the following response:
The details can be accessed with jsonpaths such as $.steps.trigger.error.response.body.error.errors[0].domain or $.steps.trigger.error.response.body.error.errors[0].reason