A **Segment** is a dynamic audience: instead of listing members one by one, you define a **rule** (a *predicate*), and SendOps works out who matches. As contacts' attributes and engagement change, SendOps re-evaluates the Segment and updates its membership — you never add or remove members by hand. Compare this with a static [List](/audience/lists), whose membership is fixed until you change it.

Segments live in the **Audience** area of the SendOps dashboard.


  A Segment is authored one of two ways: **managed** — created and edited in the SendOps dashboard (or through the API) — or **git-backed** — defined as code in a connected repository and read-only in the app. You can move a Segment between the two at any time. See [Managed vs git-backed authoring](/audience/managed-vs-git-authoring) for the full picture; either way, membership is always evaluated automatically from the rule.


## The Segments page

The **Segments** page lists every Segment in your organization. Each row shows:

- **Name** and **Key** — the display name and a stable, org-unique slug.
- **Status** — see [Segment status](#segment-status) below.
- **Evaluation** — how membership is kept current: **Incremental** (updated as events arrive), **Sweep** (recomputed on a schedule), or both.
- **Members** — the size of the Segment at its last evaluation.
- **Created** — when the Segment was created.



### Segment status

| Status | Meaning |
|---|---|
| **Active** | The Segment is valid and being evaluated. |
| **Paused** | Evaluation is stopped; membership is frozen at the last run. |
| **Invalid** | The rule no longer compiles, so it can't be evaluated. The detail page explains why. |
| **Archived** | A repository-managed Segment whose source file was removed. |


  The member count reflects the **last evaluation**, not this instant. A **Paused** or **Invalid** Segment isn't being re-evaluated, so its membership stays frozen at the last good run. Always check the status before treating a count as current.


## Segment detail

Open a Segment to see its metadata (key, member count, description, when it was created, and when it was **last evaluated**), plus:

- **The predicate** — the rule that defines membership. For a **git-backed** Segment it's shown in a read-only, copyable code block; for a **managed** Segment, use **Edit** to change the rule right there in the built-in editor. If the Segment is **Invalid**, an alert above it explains what's wrong.
- **Source** — if the Segment is managed in a connected repository, a **Managed in git** badge appears with the source file path, a link to **edit it in GitHub**, and when it last synced. Otherwise the Segment is **managed** — created and edited here in the app.
- **Members** — a paginated table of the contacts currently in the Segment, with each member's **Email**, **Contact ID**, and **Entered** time (when they most recently entered the Segment).



### Pausing and resuming

If you have the **"manage segments" permission** (`segments.manage`), the detail page of a **managed** Segment shows a **Pause** (or **Resume**) button:

- **Pause** stops SendOps from re-evaluating the Segment. Its membership freezes at the last run and its status becomes **Paused** — useful when you want to hold a Segment steady or stop churn while you investigate something.
- **Resume** puts an active evaluation back in place; the Segment returns to **Active** and starts updating again.

You'll be asked to confirm before the status flips. Pause/resume isn't available for **git-managed** Segments — control those from the connected repository instead.

## How the rule works

A Segment's predicate is an expression that's either true or false for each contact. It can reference the contact's custom [attributes](/audience/attributes), their engagement events (opens, clicks, and so on), and their subscription state. For example, a rule like `attr.plan = "pro" and attr.region = "eu"` selects every contact whose `plan` attribute is `pro` and whose `region` is `eu`.

You write rules in **SendQL** — see the full [Segment syntax reference](/audience/segment-syntax) for every term, operator, and worked examples. Because the rule references attributes by name, the [attribute registry](/audience/attributes) is what defines the vocabulary available to your Segments.

## Where Segments come from

You author a Segment one of three ways, and you can move it between them at any time:

- **In the dashboard.** Create a Segment from the Segments page — or the **Create segment** action in the ⌘K command bar — and write its rule in the built-in editor. The editor checks the rule as you type, previews how many contacts it matches, and keeps a version history you can restore from. Managed Segments stay fully editable here.
- **As code, in a connected repository.** Define Segments and attributes alongside your templates; SendOps validates the rule and syncs it on every push, and a removed source file moves the Segment to **Archived**. See [GitHub integration](/templates/github-integration).
- **Through the SendOps API.** Read Segments and their members, and **preview a rule** (see how many contacts it matches) before committing to it. See the [Lists & Segments API reference](https://developers.sendops.dev/api-reference/lists-segments).

## What's next?

- [Attributes](/audience/attributes) — the custom contact fields your rules reference.
- [Lists](/audience/lists) — static audiences with explicit membership.
- [Lists & Segments API](https://developers.sendops.dev/api-reference/lists-segments) — read Segments and preview predicates programmatically.