# Error handling & Monitoring

Frends implements multiple ways to handle errors from Processes. While the best option is to have no errors, working with multiple external systems means not everything is controlled by Frends. 

Frends error handling works as a **layered system** with three distinct scopes: within a single Process, over the Process execution, and across the entire Environment from a number of executions. A well-designed integration typically uses all three together — the innermost layer recovers from expected local failures, the middle layer reacts when a Process as a whole fails, and the outermost layer watches patterns that no single Process execution could ever detect on its own.

## Process error handling

Process-level error handling covers failures that occur *within* a single Process execution. Frends provides two mechanisms here — a Catch shape for recovering from known errors inline, and an Error Subprocess for handling anything that goes unhandled by the time the Process stops.

### Catch shape

Each Process in Frends can implement its own error handling using a **Catch shape** (Try-Catch scope). This is the right choice when an error is *known and recoverable* — skipping bad records, applying retry logic, or logging failures without aborting the rest of the execution.

<figure><img src="/files/DjbsD6AUtK9Mw0CCfCl1" alt="Image shows a Catch shape being used within Frends Process."><figcaption><p>Common structure in Frends Process to handle an error within the Process.</p></figcaption></figure>

#### Error Subprocess

When an error is not caught inside the Process, the **Error Subprocess** takes over. If any unhandled error occurs, the configured Subprocess is invoked to handle it — typically sending an alert, writing to a database, or archiving the failed payload. Because execution has already stopped at this point, this layer is suited for *alerting, notification, and cleanup*, not for resuming the original logic.

<figure><img src="/files/5k9SICVULTyCnMUs6FkM" alt="Image showing parameters for Subprocess to call on unhandled error."><figcaption><p>Parameters for Subprocess to call on unhandled error are specified by the Subprocess.</p></figcaption></figure>

To learn more about error handling in Processes, [we have an excellent guide covering how it works](/guides/development/how-to-handle-errors-in-frends-processes.md).

## Monitoring Rules

For conditions that only become visible across many executions, Frends includes **Monitoring Rules**. These operate at Environment level and can detect cross-process patterns, volume anomalies, and frequency issues — for example, the same error occurring five or more times in one hour, or a daily sync that has not run. Monitoring Rules target **promoted values** from Processes, and can trigger either a simple email alert or a full Process to handle the condition.

<figure><img src="/files/gVSHPeole2QiaIIXscQA" alt=""><figcaption><p>Monitoring rule view showing instance counts for the specified rule.</p></figcaption></figure>

To learn more about Monitoring Rules, [check out the reference documentation about them](/reference/frends-6.2.0/administration/monitoring-rules.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.frends.com/docs/frends-6.2.0/management-and-operations/dashboard-and-monitoring/error-handling-and-monitoring.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.