Effective error handling is crucial for building reliable and resilient stories. This guide outlines the key methods for configuring retries, advanced error logging, and comprehensive monitoring to ensure you are immediately aware of, and can recover from, potential issues in your story.
Useful resources
This story from our Library that utilizes Tines Records to improve story performance.
This story in our Library has general best practices around story building (it goes hand-in-hand with the blog below).
This blog on Optimizing Tines Stories - Tips and Tricks for Building Efficiently
Tines University.
Configuring retries and error statuses for HTTP requests
To manage temporary service interruptions, you can configure your HTTP request actions to automatically retry upon failure.
Set retry on status
Note: This setting must be enabled for the "Retries" setting (section below) to work.
Useful examples include:
Status code 0 (Timeout): This is useful when a service is completely unreachable and does not send a response.
400–499 status codes (Client errors): These typically indicate user-side issues, such as a 401/403 credential problem or a 404 not-found error.
500-599 status codes (Server errors): These error codes indicate that something is wrong on the server side, such as the service being unavailable.
Set retries
You can set the number of times that Tines will retry your action, up to a maximum of 25.
These retries can be configured to execute on specific status codes with retry on status, such as 500 errors, which often indicate temporary service unavailability.
Note: The precise calculation for the time between retries is available in the product documentation.
Log error on status
Use the "log error on status" feature to handle specific error types. Similar to retry on status, examples include:
Status code 0 (Timeout).
400–499 status codes (Client errors).
500-599 status codes (Server errors).
Retries in templates
Even when using templates with a friendly graphical user interface, you can still configure retries by selecting the action, choosing the "look inside" option, and configuring the HTTP parameters to set "retry on status".
Advanced error logging techniques
Beyond standard status codes, you can implement methods to detect errors that are hidden within a successful response.
Handling errors in a 200 success body
Some APIs, like Slack, may return a 200 status code even when the request wasn't actually successful. In the example below, omitting the channel ID for a Slack message still results in a 200 status code, but the response body contains an error.
To catch these, use the log error if feature. First, you must inspect the event data's body structure to locate the error object.
Note: The OUTPUT variable: The log error if function examines the action's output before the event is sent. This variable is distinct and cannot look at upstream event actions.
Configure log error if to check the OUTPUT variable for the presence of this error object path: IS_PRESENT(OUTPUT.body.error). This is the system default when you add this option.
Monitoring and notification best practices
There are two primary ways to receive alerts about action failures:
By setting a failure path on a specific action.
By setting up story-level monitoring.
By setting up action-level monitoring.
Action-specific failure path
Configure a separate flow to run after an HTTP request action fails using the "emit failure path" feature.
This creates a dedicated path for sending failure notifications, whether by email, Slack message, or another channel. You can also configure it to an HTTP request action that automatically opens a ticket in an external system like Jira.
Story-level monitoring
Monitoring can be set up in the story settings to send notifications when an action fails.
Entire story failure
Configure the story settings to notify you when any action fails within the story.
Action-specific monitoring
For finer control, you can set up monitoring for a specific action by going to the action's Status tab and selecting monitoring.
Notification methods
Notifications can be sent to:
An email address.
A webhook URL: This allows you to trigger a separate story for customized error handling.
Note: These must be set at the story-level, including for action specific monitoring.
Tenant health page
You can get a high-level view of story activity in the Tenant health page.
The "Live activity" section there provides a count of errors for each story listed.
Best practices for failure notification content
When configuring failure notifications, include crucial troubleshooting data to quickly diagnose the issue. Essential data can include:
The date of the failure.
The story ID and story name.
The story URL (to redirect you to the exact story).
The ID of the story run.
Tip: These 3 can be pulled using the META variable.
The error message.
The status code.
Tip: These can be pulled via upstream reference paths to the action that returned the error.
Note on built-in vs. custom notifications. Using the built-in story monitoring for email results in a pre-configured, linked email. Using a webhook, however, allows for greater customization and integration with platforms like Slack.