# Owner alerts and webhooks

Blink alerts your instance owners to events that may mean a console account has been misused. Alerts show in the console and, if you set one up, are also sent to a webhook.

## What raises an alert

- A fleet limit was reached: someone tried to start more Access sessions, reboots or chats with devices' users in an hour than allowed. See [Fleet limits](/configure/security-settings/#fleet-limits).
- A new instance owner, a new instance role assignment, or a new organization Owner. Removing an instance owner raises an alert too.
- An instance owner reset someone's password, two-factor and passkeys.
- Role and access changes: roles created, changed or deleted, members' roles changed, group roles given or removed, and instance role assignments changed or removed.
- A wrong passkey or code entered to confirm a high-risk action.
- An organization's Access device was refused by the organization's agent IP rule (**Agent blocked by IP rule**). Blink raises it at most once per organization per day. Refusals by the console IP rule are recorded in the activity log but not alerted. See [Restrict access by IP address and country](/configure/ip-and-country-rules/).
- The console IP rule was cleared outside the console to get a locked-out team back in (**Console IP rule cleared**).
- Security changes that could silence other alerts: the alert webhook set or removed, the high-risk confirmation setting loosened, or a fleet limit loosened.
- An Access device could not enroll because your plan's device limit is reached. The alert is titled **Device limit reached**, and people with the **View license** permission get an **Open License** link with it. The activity log records it as **Enrollment refused: device limit reached**, at most once an hour. See [Access devices](/configure/plans-and-limits/#access-devices).

Every alert is also a record in the activity log, which stays the complete history of who did what.

## See alerts in the console

Instance owners see a bell icon at the top of the console. A number on it shows unread alerts.

1. Select the bell to open **Alerts**.
2. Read the list. The newest alerts are at the top.
3. Select **Mark all read** to clear the count, or **Instance activity** to open the full activity log.

An **Agent blocked by IP rule** alert has an **Open agent IP rules** link to the rule, shown while that organization is the one selected and you have the **View agent IP rules** permission.

Alerts are kept for 90 days. If the same person repeatedly hits a fleet limit or enters a wrong confirmation code, Blink shows one alert per hour for it; every attempt is still in the activity log. A device refused at the device limit is different: Blink records it in the activity log, and raises the alert, at most once an hour for the whole server, however many devices are refused.

:::note
Only instance owners see the bell. To give other people a view of what happens, use the **Activity** page (organization activity, with the **View activity** permission) or **Instance** › **Activity** (with the **Instance activity** permission).
:::

## Send alerts to a webhook

A webhook sends each alert to another system as it happens, for example a team chat channel or your monitoring tool. You need the **Manage security settings** permission.

1. Open **Instance** › **Security**.
2. Under **Owner alerts**, enter the **Webhook URL**.
3. Select **Save webhook**.
4. Select **Send a test** to check that the alert arrives.

The URL must use `https` (plain `http` is accepted only for an address on the Blink server itself) and can't contain a user name or password. Blink keeps it encrypted and shows only its host name afterwards, because the URL may contain a token. To change it, enter a new URL under **Replace the webhook URL**. To stop sending alerts, select **Remove**.

:::caution
Setting or removing the webhook raises an alert itself, so a removed webhook can't go unnoticed.
:::

### What the webhook receives

Blink sends an HTTP `POST` with a JSON body like this:

```json
{
  "type": "blink.alert",
  "instance": "<your server's instance id>",
  "id": "<alert id>",
  "at": "2026-11-11T09:30:00Z",
  "kind": "new_admin",
  "title": "<short title>",
  "detail": "<one-sentence description>",
  "actor": "<email of the person who did it>",
  "action": "<the activity log action>",
  "text": "<title>: <detail>"
}
```

The `text` field is the title and detail in one line, which most chat tools show as is. `actor` and `action` are left out when they are empty. The `kind` is one of:

| Kind | Meaning |
|---|---|
| `mass_action` | A fleet limit refused someone |
| `new_admin` | A new instance owner, instance role assignment or organization Owner |
| `mfa_reset` | An instance owner reset an account's password and two-factor |
| `role_change` | Roles, members' roles, group roles or instance role assignments changed, or an instance owner removed |
| `sudo_failed` | A wrong code or passkey when confirming a high-risk action |
| `security_change` | The webhook was set or removed, high-risk confirmations or fleet limits were loosened, or the console IP rule was cleared outside the console |
| `device_limit` | An Access device could not enroll because the plan's device limit is reached |
| `ip_blocked_agent` | An organization's agent IP rule refused an Access device |
| `test` | A test sent with **Send a test** |

The webhook must answer with a `2xx` status within 10 seconds. Blink does not follow redirects. If **Send a test** fails, the console only says that it failed; the reason is in the server log.