> ## Documentation Index
> Fetch the complete documentation index at: https://docs.condense.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Runtime alerts for connectors and transforms

> Set alerts on CPU, memory, consumer lag and more for your connectors and transforms. Choose a threshold and duration, and get notified in the app and by email.

Condense can watch the health of your deployed connectors, transforms and custom connectors, and notify you when one crosses a limit you set, such as high CPU use or a growing consumer lag. You choose the limit, and Condense does the watching.

## Overview

An alert is a simple rule: "tell me if this measurement stays above this limit for this long." Condense measures how each component is running and checks those measurements against your rules, so you hear about a problem before it turns into an outage.

You do not write any queries. The queries behind each alert are managed by Condense and cannot be modified.

> [!NOTE]
>
> Runtime alerts watch how a component is running, not what is inside your messages.

## Alerts you can configure

Each alert is predefined. Pick the ones that matter for the component you are deploying.

| Alert | What it tells you | How it is set |
| :- | :- | :- |
| **CPU Utilization** | How much of its processing capacity the component is using. | Threshold and duration |
| **Memory Utilization** | How much of its memory the component is using. | Threshold and duration |
| **Consumer Lag** | How far behind the component is in reading messages from its Kafka topic. A growing lag means messages are arriving faster than they are processed. | Threshold and duration |
| **Response Latency** | How long the component takes to respond. | Threshold and duration |
| **Active Connections** | How many connections to the component are open. | Threshold and duration |
| **Consumer Group Health** | Whether the group of consumers reading a topic is active. It fires when the group is empty or dead, which means the component is no longer consuming data. | Fixed, fires immediately |
| **CrashLoopBackOff** | Whether the component keeps starting and crashing again and again, a state Kubernetes reports as CrashLoopBackOff. It needs immediate action because the component cannot start. | Fixed, fires immediately |

> [!NOTE]
>
> These are examples of the metrics you can alert on. More predefined alerts may be added in later releases.

### Which alerts apply to which component

* **Consumer Lag and Consumer Group Health** apply to components that read from a topic, such as transforms and output connectors. They do not apply to input connectors, which only write data. For a custom connector, set up its consumer group first.
* **Response Latency** applies to components that expose HTTP.
* You can set **one alert per metric** on a component. Trying to add a second one for the same metric is blocked, and you can edit the existing one instead.

## Set up an alert

You can configure alerts in two places:

* **While you deploy** a connector, a transform or a custom connector.
* **Later, from the Pipeline page**, for a component that is already running.

For each alert you set:

| Setting | What it controls |
| :- | :- |
| **Threshold** | The limit the measurement must cross. Available for the alerts marked "Threshold and duration" above. |
| **Duration** | How long the limit must stay crossed before the alert fires. A longer duration filters out short spikes. Available for the alerts marked "Threshold and duration" above. |
| **Enable or disable** | Turns the alert on or off without deleting it. A disabled alert is not checked. |
| **Email recipients** | Who receives the email when the alert fires. |

Consumer Group Health and CrashLoopBackOff have no threshold or duration. They fire as soon as the condition is true.

## How an alert behaves

Condense checks your enabled alerts on a regular schedule against the metrics it already collects from your components. Each alert is always in one of two states.

```mermaid theme={null}
stateDiagram-v2
    [*] --> Normal
    Normal --> Firing: Limit crossed for the full duration (notification sent)
    Firing --> Firing: Limit still crossed (no repeat notification)
    Firing --> Normal: Limit no longer crossed (recovered)
```

* **Fires once.** While the problem continues, Condense does not send the same notification again, so a long incident does not flood your inbox.
* **Recovers.** When the measurement drops back within the limit, the alert returns to Normal.
* **Fires again.** If the problem comes back after recovery, Condense sends a new notification.

## How you are notified

When an alert fires:

* An **in-app notification** is created immediately.
* An **email** is sent to the alert's recipients, if SMTP is configured for the environment. See [Configure SMTP for alert emails](https://docs.condense.io/condense/v2.6.0/alerts/smtp-configuration.md).

If an email cannot be delivered, it is marked **Delivery Failed** and shown in the alert history. The in-app notification is not affected.

## Roles and permissions

| Operation | Environment Admin | Maintainer | Developer | Viewer |
| :- | :-: | :-: | :-: | :-: |
| View alerts and their status | **✓** | **✓** | **✓** | **✓** |
| Create, edit, enable, disable or delete alerts | **✓** | **✓** | **✕** | **✕** |

Roles without permission see the alert controls locked instead of hidden.

## Best practices

* Set a duration long enough to ignore short spikes, and short enough to catch real problems early.
* Configure SMTP before you rely on email recipients.
* Review disabled alerts from time to time, so a component is not left unwatched by mistake.

## Common pitfalls

* **Recipients added, no emails received.** Email is sent only when SMTP is configured for the environment. Without it, you get the in-app notification only.
* **An alert never fires.** Check that the alert is enabled. Only enabled alerts are checked.
* **Too many alerts from short spikes.** Increase the duration.
* **No threshold field for an alert.** Consumer Group Health and CrashLoopBackOff are fixed alerts. They have no threshold or duration.

## Frequently Asked Questions

### Can I write my own alert query?

No. The queries behind the predefined alerts are managed by Condense and cannot be modified. You control the threshold and duration for the alerts that have them.

***

### Can I set up alerts after a component is deployed?

Yes. Open the Pipeline page and configure the alerts for that component.

***

### Will I get repeated emails while a problem continues?

No. Condense sends one notification when the alert fires and suppresses duplicates until the alert recovers.

***

### What happens if the problem comes back?

After the alert recovers, a new occurrence sends a new notification.

***

### Do I need SMTP to get alerts?

No. You always get in-app notifications. SMTP adds email delivery.

***

### Why can I not set a second alert for the same metric?

A component can have one alert per metric. Edit the existing alert to change its threshold, duration or recipients.

## Related documentation

* [Configure SMTP for alert emails](https://docs.condense.io/condense/v2.6.0/alerts/smtp-configuration.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.