> For the complete documentation index, see [llms.txt](https://docs.brigge.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brigge.ai/documentation/brigge-for-operators/history-and-retries.md). # History & retries ## Working with the history page Brigge provides full visibility into current and previous pipeline runs from the [*History* page](#user-content-fn-1)[^1]. For example:

Every run is displayed as a single entry, grouped by day. For each run, you can see key details and the current status/outcome. You can also select options to [access deep-dive logs and associated information](#logs-detailed-logs-for-this-run), and to [manage run failures](#retrying-a-failed-run). {% hint style="info" %} The colour/icon associated with the 'date in view' marker reflects the 'worst' status for that day. Ideally, everything will be successful; if there are warnings, they are reflected here. If there are warnings AND failures, a red failure icon is shown. {% endhint %} ### Anatomy of a history item Each pipeline run is displayed as a row, with key information and options so you can see the outcome and access more information and options if needed. For example:

History item details & options

#	Summary
Trigger time	The time the run was triggered and queued. When a pipeline is triggered (either manually or automatically), it is added to a queue for processing. With this in mind, the time logged here may not be the same as the `start` time noted in the detailed logs for this run.
Run status	The current status of this run. For more information, please refer to Run status indicators.
Run ID	A unique (auto-generated) ID for this run.
Name & group	The pipeline name, appended with the pipeline group (in brackets). Click the name to access this pipeline in the editor. The version displayed in the editor will be the version associated with this run, which might NOT be the latest.
Key details	Key details for this run: Priority. Can be `high`, `medium`, or `low` as defined in the configuration settings for this pipeline. Environment. The environment in which the pipeline ran. Run time. The time taken for the pipeline to run. Trigger type. How the run was initiated, as determined by the pipeline's trigger node. CPU time. The active CPU time for this run. Data usage. The volume of data processed during this run. Tokens. The number of tokens used during this run. Score. The efficiency score associated with this pipeline.
Full logs / retry	Click the `logs` icon to view logs and associated information for this run: If the run has failed, the `failed run` icon is also displayed so you can retry:

### Run status indicators At any given time, a pipeline run can be in one of the following states: * Pending * Running * Completed - success * Completed - failed * Completed - warnings * Stopped * Stopping As you scan the *History* page, you'll see these states represented as icons, where grey is pending, blue is running, green is success, orange is warning, and red is failure or stopped.

Run status icons

The icons displayed vary, depending on the run type:

Icon	Summary	Icon	Summary
	Automated or manual run pending		Retry run pending
	Automated or manual run in progress		Retried run in progress
	Automated or manual run successful		Retried run successful
	Automated or manual run completed with warnings		Retried run completed with warnings
	Automated or manual run failed or stopped		Retried run failed or stopped

### Searching & filtering history items You can use search and filter options at the top of the page to refine the list of history items:

From here, you can: * Search for runs associated with a given pipeline name (enter the full name or any part of a name - the search is not case sensitive). * Show runs for a specific [environment](/documentation/brigge-for-transformers/environments.md). * Show runs in a specific [state](#run-status-icons). ### Pipeline run details You can access detailed information for any pipeline run - whether to review a completed run or monitor one in progress. Click the `logs` icon for the run you want to check. For example:

This opens the *Pipeline run details* viewer:

Here, information is organised across a set of tabs, detailed below.

Logs (detailed logs for this run)

The `logs` tab shows a chronological, timestamped record of every action taken during the run.

For each entry, you will see: * The time the action occurred (to millisecond precision) * An icon identifying the step (i.e. [node](/documentation/brigge-for-transformers/pipelines/pipeline-nodes.md)) type * A plain-English status message As the pipeline runs, entries are added sequentially, so you can follow the preparation, authentication, payload handling, and processing progress as each step completes. As you scroll through the logs, hover your cursor over any icon to confirm the node type:

Click any log entry to view the [payloads](#payloads-all-payloads-processed-in-this-run) and [transactions](#transactions-details-for-all-requests-and-responses-for-this-run) for this step. When you navigate back to the `logs` tab, you'll notice that a filter is applied, and you only see logs up to the point you chose to view `payloads`. Select the `clear filters` option to view all logs again.

Payloads (all payloads processed in this run)

When a pipeline runs, payloads are output from each step. You can view all available payloads from the `payloads` tab (as shown below) or, if a specific log entry is selected, the payloads associated with that step. For example:

To view payload contents, click the item you want to view from the `payloads` tab. The list auto-filters to only this item, for example:

Click the filtered item to view payload content. For example:

Payload options are summarised below:

#	Function	Summary
1	`Copy`	Copy the payload to your computer's clipboard.
2	`Prettify`	Makes the payload more readable.
3	`Create schema`	Create a new schema (based on this payload) that can be applied in map nodes within the associated pipeline. For more information, see Schemas.
4	`Back to payloads`	Exit this payload, then click `clear filters` to view all payloads again (or select another tab).

Transactions (details for all requests & responses for this run)

When Brigge calls an external system (via an HTTP request, an SFTP transfer, an S3 call, etc.), details of what was sent (the request) and what was returned (the response) can be viewed from the `transactions` tab in the pipeline run history. For example:

Since calls to external systems are made via [connector nodes](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/connector-node.md), you will find `connector` entries here - each is associated with one or more *transactions*. One transaction correlates to one call to handle data. If multiple payloads are received/sent (for example, if incoming data is paginated or data is sent to a system in batches), the associated connector node will have multiple *transactions.* Click a connector entry to view transaction details. Here, you'll see one transaction for each call made in this step, and you can drill into each one for details. {% hint style="info" %} This is particularly useful for investigating pipeline run warnings or errors at the connection level. For example, if unexpected data was returned, or a system wasn't reachable. {% endhint %} To view transactions for a connector step, select the connector entry and then the transaction. For example:

From here, you can choose to view the `request` and `response` details. For example:

#### Request details The following details can be viewed for a connection request:

Section Summary

URL The request URL associated with the connector endpoint, together with the request method (for example, GET or POST).

Headers Header information passed into the request.

Body

Section	Summary
URL	The request URL associated with the connector endpoint, together with the request method (for example, `GET` or `POST`).
Headers	Header information passed into the request.
Body	Any content that was passed in the `body` of the request. If the request was to receive data, the request body is often empty, but if the request is to send data, the body will typically (though not necessarily) include the data to be pushed. You can use options to copy `body` content to your clipboard, or toggle the display between `form` and `raw` content. For example:

Any content that was passed in the body of the request. If the request was to receive data, the request body is often empty, but if the request is to send data, the body will typically (though not necessarily) include the data to be pushed.

You can use options to copy body content to your clipboard, or toggle the display between form and raw content. For example:

{% hint style="info" %} Use the `copy as curl` option to copy the exact HTTP request (URL, method, headers, auth tokens, and body), formatted as a cURL command you can run directly in a terminal. {% endhint %} #### Response details The following details are available for a connection *response*:

Section Summary

URL The request URL associated with the connector endpoint, together with the response type (for example, 201).

Headers Header information received from the external system.

Body

Section	Summary
URL	The request URL associated with the connector endpoint, together with the response type (for example, `201`).
Headers	Header information received from the external system.
Body	Any content received from the external system in the response `body`. If the original request was to receive data, the response `body` will often be payload data for onward processing in the pipeline. If the request was to send data into the external system, the response `body` typically includes the outcome of an attempt to create or add items. You can use options to copy `body` content to your clipboard, or toggle the display between `form` and `raw` content. For example:

Any content received from the external system in the response body.

If the original request was to receive data, the response body will often be payload data for onward processing in the pipeline. If the request was to send data into the external system, the response body typically includes the outcome of an attempt to create or add items.

You can use options to copy body content to your clipboard, or toggle the display between form and raw content. For example:

Summary (AI summary of run outcome and exception-handling guidance)

If you are investigating an issue with a pipeline run, the `AI summary` tab is a great place to start. Here, you'll find a summary of the run outcome and, if warnings or errors occurred, an explanation of what happened and how you can resolve any issues. For example:

## Retrying a failed run A pipeline might fail for reasons that typically fall into one of three categories: pipeline setup, external system issues, or authentication. Depending on the category, Brigge retries the run automatically before logging it as a failure. The number of retries attempted for each type of run failure is summarised below:

Category Summary Retries

Pipeline setup

Category	Summary	Retries
Pipeline setup	A condition or setting in the pipeline setup causes the run to fail. For example: A system endpoint is configured to accept status codes in the range `200-299`, and a `401` is returned. A mapped field includes a transform function that is incompatible with the actual field type (e.g. applying an `array_math` transform for a flat, `string` field).	0
External system issues	A general issue with the external system prevents a connection from being made.	2
Authentication	Authentication credentials associated with a connector node fail.	1

A condition or setting in the pipeline setup causes the run to fail. For example:

A system endpoint is configured to accept status codes in the range 200-299, and a 401 is returned.
A mapped field includes a transform function that is incompatible with the actual field type (e.g. applying an array_math transform for a flat, string field).

External system issues A general issue with the external system prevents a connection from being made. 2

Authentication Authentication credentials associated with a connector node fail. 1

### How do I know if a pipeline run has failed?

Action	Summary
Check your dashboard	The Brigge dashboard provides a bird's-eye view of pipeline run outcomes for any given time period (by default, the last month).
Check historic logs	The run history page shows the outcome of all pipeline runs, grouped by day.
Check email notifications	If a pipeline is configured to trigger email notifications when a run fails, defined recipients receive an email alert for any failures.
Monitor real-time logs	If you're running a pipeline manually (i.e. from the pipeline editor), the `logs` panel displays logs in real time, so any failures are immediately apparent.

### **Investigating a run failure**

Check the AI summary for this run

It's often useful to check the [AI summary](#summary-ai-summary-of-run-outcome-and-exception-handling-guidance) for the run; this can provide valuable insights into what might have happened and guidance on resolving any issues. To access the AI summary for a run, select `history` from the navigation menu, then click the `logs` icon and select the `AI summary` tab.

Check the logs and associated assets for this run

Logs will show exactly where the pipeline failed. Select the failed step to review [payloads](#payloads-all-payloads-processed-in-this-run) and [transactions](#transactions-details-for-all-requests-and-responses-for-this-run). If the failure occurred at a [connector](/documentation/brigge-for-transformers/pipelines/pipeline-nodes/connector-node.md) step, transaction details will show the exact request(s) and responses sent/received. Also consider the following: * Are the associated system [credentials](/documentation/brigge-for-engineers/credentials.md) up to date? * Is the pipeline connector node configured correctly? For example, could the issue be related to a missing/incorrect variable or parameter? * Is the external system experiencing any issues? * Was the associated system built by someone in your organisation using the Brigge system builder? If yes, it may be worth checking the issue with the owner. For connectors and any other nodes, check the payloads: are they as expected for the associated step? If no, what happened in the preceding step(s)?

Review the pipeline configuration

By now, checking payloads and transactions will likely have pinpointed the issue. If not, check settings for the failed [node](/documentation/brigge-for-transformers/pipelines/pipeline-nodes.md) and any preceding nodes.

### Retrying a failed run {% hint style="danger" %} Before retrying a pipeline run, it's important to check whether any data was synced in the failed run. If yes, the pipeline may need to be adjusted (or a new one added) to handle duplicate updates. {% endhint %} Having determined why a pipeline run failed and addressed the issues, you can use the `retry` option to re-run the pipeline.

Cover image

		Cover image
Select `history` from the navigation menu and find the failed run that you want to retry. If necessary, use filter options to refine the list; the `status` option is particularly useful for this task, as you can choose to display only failed runs. For example:		1.png
Click the `failed run` icon. For example:		2.png
Click the `retry` button. For example:		3.png

Select history from the navigation menu and find the failed run that you want to retry. If necessary, use filter options to refine the list; the status option is particularly useful for this task, as you can choose to display only failed runs. For example:

1.png

Click the failed run icon. For example: 2.png

Click the retry button. For example:

3.png

[^1]: **How do I get there?**\ Select *History* from the main navigation menu: ![](https://2172380191-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8IqdqwZowcxtFpZfLa6k%2Fuploads%2Fuh8A0QL1MOo8oKHbGF4u%2Faccess%20history.png?alt=media\&token=631b1a3a-8fe1-4614-b2d5-697b6adb1398)