Monitoring Integrations

Once your integration has been released, the integration page will start to populate with a range of metrics. To view these metrics, open your integration from the Integrations page. You will be presented with 2 tabs-Overview and Invocations:

The Overview tab provides outline details of your integration, including:

• Performance metrics
• Details of which experiences have been configured to call the integration
• A changelog showing the released versions

The Metrics card displays 5 key integration metrics and a visualization of each metric for the chosen reporting period:

• Executions - the rate at which the integration was executed. Hovering over a point on the graph will provide a breakdown of successful, failed, timed-out and rate-limited executions
• Duration - the average duration of the executions
• Request size - the average size of the request payload
• Response size - the average size of the response payload
• Scheduling - the rate of scheduled executions

INFO: By default, the reported metrics are shown for the last hour. You can change this by making a selection from the select box on the top right of the card.

The Experiences card shows you a list of experiences that have been configured to call the integration:

By default, the list will display the experiences that have been configured to call any version of the integration. If you are only interested in a particular version, you can filter the list of experiences to show only those that are linked to a specific version.

To do this, make a selection from the select box in the top-right hand corner of the page:

You can jump to any of the experiences listed by selecting the experience name.

The Details card displays the integration description and also the changelog history.

As mentioned earlier, each time you make a change to an integration, a new version is created. An entry will also be inserted into the changelog. For each version, you will find:

• Version number
• Timestamp of the release
• Changelog of updates the release contains
• Name of the user that released the version

The Invocations tab provides a stream of your integration's invocations, including the execution time, duration, and status:

Refer to the following diagram for an overview of how an integration moves from one state to another after being scheduled or invoked:

Let's take a look at the details of each invocation status in more detail, as this is likely to be the most useful information for resolving any problems.

INFO: The final execution status for each invocation determines the status reported in the Invocations table.

Each invocation of an integration can have one of six statuses:

• Scheduled - The integration has been scheduled to be invoked at some future point
• Cancelled - The integration was been scheduled to be invoked at some future point but the invocation was subsequently cancelled
• Rate-limited - The integration did not execute as the rate limit was reached. See Other settings
• Timed out - The integration was executed and finished but timed out. An invocation will timeout if it hits the execution timeout limit: the invocation is then terminated
• Failure - The integration was executed and finished but encountered an error during execution
• Success - The integration was executed and finished without errors

You can get more details about each invocation by selecting it from the list. In the following example, the user has selected an invocation that finished with success:

In the above example, we see that the integration was invoked by a linked experience.

TIP: If the integration was invoked by an experience, we will provide a link to it.

All external HTTP requests are automatically logged. Selecting will allow you to expand the entry and see detailed information for the request:

This information is useful for debugging long execution times as slow HTTP requests are generally the reason integrations time out.

When you open the Invocations tab, we will display the most recent 30 invocations covering the last 30 days of invocations.

Clearly, whilst viewing the list of invocations, additional invocations may be occurring. You can refresh the list of invocations to display:

• The most recent 30 invocations > Load newest (resets the table contents)
• The next 30 invocations since the last page load > Load newer (loads additional table rows)
• The previous 30 invocations since the last page load > Load older (loads additional table rows)

The following diagram will help explain the concept:

When debugging, it is often useful to filter the table of invocations. You might filter by status, for example, or source.

To open the filters, select

The available filters are self-explanatory but it is important to understand that the filters are ANDed together but that the options within each filter are ORed together.

So in the following example, the filter would return invocations with:

• A version number of 1.0 OR 1.1 AND
• Those invoked by an experience AND
• Those with a final status of Failure OR Timed out:

One filter that is particularly useful for debugging is key.

INFO: Key refers to the key object passed into experiences.

You can use this to return only those invocations that match the key-value pair. In the following example, the user has chosen to return invocations matching the key campaign and value summer:

By default, we display only those invocations that have completed, irrespective of their status. To view invocations for scheduled integrations, change the option in the combo box to the right of the page to Scheduled: