> For the complete documentation index, see [llms.txt](https://docs.fullsession.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fullsession.io/15.-alerts-and-notifications.md).
# 15. Alerts & Notifications
Alerts let FullSession tell you when an audience changes size — *"let me know when fewer than 100 people reach checkout this week"* or *"alert me when active mobile users drop 20% month over month."* When an alert's condition is met, FullSession notifies you in the app, by email, or through Slack/Zapier. This chapter covers what alerts can watch, how to build them, how they're delivered, and how to work the in-app notification center.
> Alerts are a plan-gated feature, governed by permissions (view / create / edit / delete). If you don't see Alerts, it isn't enabled for your account or role.
***
### 15.1 What Alerts Do
It's important to be precise about what an alert watches, because it's narrower than many analytics tools:
> **An alert watches the number of unique users matching a segment, over a time window.**
That's the single metric. You pick a **segment** (\[Chapter 11 — Segments]) and a **time frame** (daily, weekly, or monthly), and FullSession notifies you when the count of unique users in that segment meets your condition — either crossing a fixed number or changing significantly versus the previous period.
#### What alerts can't watch
Alerts do **not** fire on error spikes, rage/dead clicks, conversion-rate drops, funnel steps, feedback scores, session duration, or custom events. If you need those, use:
| You want to monitor… | Use instead |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Conversion or drop-off changes | **Funnels** + **Lift AI** ([Chapters 12](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610#) & [14](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610#)) |
| Errors, frustration, engagement trends | **Dashboards** (review them) ([Chapter 9](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610#)) |
| UX issues affecting a goal, continuously | **Lift AI** issue detection ([Chapter 14](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610#)) |
Think of alerts as **audience-size monitors**, and Lift AI as the continuous, AI-driven issue watcher.
***
### 15.2 Creating an Alert
Alerts are created from a single dialog. You define what segment to watch, how often, and the condition.
#### The fields
1. **Alert name** — a name for the alert.
2. **Segment** — the segment whose user count you're watching (*"Segment selected for the alert"*).
3. **Frequency** — **Daily**, **Weekly**, or **Monthly** (the comparison window).
4. **Alert type** — how the condition is evaluated: **Value**, **Relative Change**, or **Absolute Change** (explained in section 15.3).
5. **Condition operator** — depends on the type:
* For **Value**: *Greater than*, *Less than*, *Equal to*.
* For **Relative/Absolute Change**: *Increased by*, *Decreased by*.
6. **Threshold** — the number to compare against (a count, a percent, or an absolute difference).
7. **Delivery & notification preferences** — covered in sections 15.4–15.5.
#### One alert per segment
> **You can have one alert per segment, per site.** If an alert already exists for a segment, you'll edit that one rather than create a second. To watch the same audience two different ways, you'd need two different segments.
***
### 15.3 Alert Conditions Explained
The **alert type** determines how FullSession evaluates the segment's user count. There are three.
#### Value — compare to a fixed number
Fires when the current count crosses a threshold you set. Operators: *Greater than*, *Less than*, *Equal to*.
> *Example:* **Weekly · Value · Less than · 100** — "alert me when fewer than 100 users reached the checkout segment this week."
#### Relative Change — percentage change vs. the previous period
Fires when the count changes by a **percentage** versus the prior window. Operators: *Increased by*, *Decreased by*.
> *Example:* **Weekly · Relative Change · Decreased by · 20%** — "alert me when the signups segment shrinks 20% week over week."
#### Absolute Change — raw difference vs. the previous period
Fires when the count changes by a **raw number** versus the prior window. Operators: *Increased by*, *Decreased by*.
> *Example:* **Monthly · Absolute Change · Increased by · 500** — "alert me when active mobile users grow by 500 month over month."
#### The time windows
| Frequency | Compares |
| ----------- | ------------------------------------------- |
| **Daily** | The last 24 hours vs. the previous 24 hours |
| **Weekly** | The last 7 days vs. the previous 7 days |
| **Monthly** | The last 30 days vs. the previous 30 days |
> **Daily frequency supports only the Value type.** Change-based comparisons (relative/absolute) are available on **Weekly** and **Monthly** frequencies.
Alerts are evaluated **periodically in the background** — they aren't real-time. FullSession checks your conditions on a regular cycle and notifies you when one is met.
***
### 15.4 Delivery: App, Email, Slack & Zapier
When an alert fires, FullSession can deliver it through several channels, chosen when you create the alert.
#### Channels
| Channel | How it works |
| ---------- | ----------------------------------------------------------------- |
| **In-app** | A notification appears in your notification center (section 15.6) |
| **Email** | An email is sent to the recipients (see below) |
| **Slack** | Posts to a Slack channel via a **webhook URL** you paste in |
| **Zapier** | Sends the alert to a Zapier hook for downstream automations |
The dialog presents these as preset choices — for example *"Get notified via App and Email,"* *"Get notified via App only,"* or *"Disable App and Email notifications"* — plus the option to **send to Slack** and **send to Zapier**.
#### Recipients
Email and in-app notifications go to the **alert's owner and site admins** by default. You can also **add specific team members** — *"Add other team members to the email or in-app notifications"* — and each recipient's app/email preference is respected.
#### Slack setup
Enable **Slack** and paste your channel's **Webhook URL** into the field. When the alert fires, FullSession posts a formatted message — the alert name, segment, threshold, the affected user count, and the date.
#### Zapier setup
Enable **Zapier** to send alert data to a Zap. The in-app dialog links you to a **tutorial**; the Zapier side of the connection is completed in Zapier itself, where the alert's data (operator, threshold, current/previous values, segment, site, and timestamp) arrives as the trigger payload.
> **Only Slack and Zapier** are supported as outbound integrations for alerts — there's no generic custom-webhook field or mobile push.
***
### 15.5 Notification Frequency & Limits
To prevent alert fatigue, FullSession lets you control how often a single alert can notify you.
#### Notify once vs. multiple
* **Notify me only once** *(default)* — you get a single notification when the condition is first met.
* **Send me multiple notifications** — you can receive repeated notifications, up to a **daily limit** you set (1–5 per day).
#### How limits behave
* An alert won't notify more than your chosen number of times per day.
* There's a built-in **cool-down** between notifications so you don't get a burst.
* If an alert hits its daily limit and isn't set to keep sending, it **pauses itself** for the rest of the day and resumes the next day automatically.
> **Tip** — start with **Notify me only once** for most alerts. Reserve multiple notifications for conditions you genuinely want repeated reminders about.
***
### 15.6 The Notification Center
In-app alerts (and other system notifications) collect in the **notification center**, opened from the bell in the top bar.
#### Tabs and overview
The panel organizes notifications into tabs, each with a count:
* **All** — everything.
* **Unread** — not yet read.
* **Snoozed** — temporarily set aside.
* **Read** — already handled.
A **Mark all as read** action clears your unread queue in one click. Each notification shows a **severity** (high / medium / low), a message, and a relative timestamp; some include a **call-to-action** link to jump to a relevant view.
#### Actions on a notification
| Action | What it does |
| ------------------ | ------------------------------------------------- |
| **Mark as read** | Moves it to Read |
| **Mark as unread** | Returns it to Unread |
| **Snooze** | Temporarily moves it to Snoozed |
| **Unsnooze** | Brings it back |
| **Open (CTA)** | Follows the notification's link, where one exists |
> **Snooze applies to notifications, not alerts.** You snooze an individual *notification* in this panel; there's no "mute this alert" toggle on the alert itself. To stop an alert entirely, disable it (section 15.7).
#### From an alert notification to the data
An alert notification names the **segment** and the **threshold** that triggered it. Note that there isn't a one-click jump from the alert into that segment's sessions — to investigate, open the named **segment** (\[Chapter 11 — Segments]) and review its sessions there.
***
### 15.7 Managing Alerts & Limitations
#### Managing alerts
| Action | Notes |
| -------------------- | -------------------------------------------------------------------------------------------------------- |
| **Create** | Requires the create-alerts permission |
| **Edit** | Update the name, condition, threshold, delivery, and preferences — **but not the alert type or segment** |
| **Enable / disable** | Turn an alert on or off (it may auto-pause when its daily limit is reached) |
| **Delete** | Remove the alert and its Slack/Zapier hooks |
To change an alert's **segment** or **type**, delete it and create a new one.
#### What alerts don't do
To set expectations clearly, these **don't exist**:
* **No alerts on metrics other than segment user count** (no error, frustration, conversion, funnel, feedback, or custom-event alerts).
* **No alert-level snooze/mute** (snooze is per-notification).
* **No severity setting on alerts** (severity appears on notifications generally).
* **No alert duplication, templates, bulk actions, or escalation rules.**
* **No time-of-day scheduling** (only the daily/weekly/monthly windows).
* **No custom webhooks** (Slack and Zapier only) and **no mobile push**.
* **No test/preview send**, and **no one-click drill-in** from an alert to its sessions.
> **The big picture** — a FullSession alert watches one thing: the **unique-user count of a segment**, compared **daily/weekly/monthly**, as a **Value**, **Relative Change**, or **Absolute Change** condition. It's delivered **in-app, by email, to Slack, or to Zapier**, with **per-alert frequency limits**, and collected in a **notification center** with read/unread/snooze and severity. It's deliberately narrow — for error, conversion, and UX monitoring, lean on **Dashboards**, **Funnels**, and **Lift AI**.
***
> **Next up:** \[Chapter 16 — Team & Account Management] covers the organization, users, roles, and the permission keys (like `alerts:create` and `dashboards:edit`) that have governed what each teammate can do throughout this manual.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.fullsession.io/15.-alerts-and-notifications.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.