--- title: Account notifications description: How Prefactor sends account events to Slack, what a message contains, and what to expect from delivery. editUrl: true head: [] template: doc sidebar: hidden: false attrs: {} pagefind: true draft: false --- Most of what happens to an agent happens while nobody is looking. A run fails overnight, or a teammate revokes a token. The record is all in Prefactor, but a record only helps once someone opens it. Account notifications close that gap by posting the moments you care about to a Slack channel, so the people who need to know hear about them when they happen. ## One channel, chosen events An account has one Slack integration, and it points at one channel through an incoming webhook. From a list of 26 account events you choose the ones that should post there, and every agent in the account follows the same choice. You can't send different events to different channels, and you can't subscribe to a single agent. If you want fewer messages, choose fewer events. The events fall into seven groups: agent, version and deployment, agent instance, user, API token, environment and team, and alert. They cover what people do, such as inviting a user or revoking a token. They cover what your agents do, such as a run failing. And they cover what Prefactor does on its own, such as raising an [alert](/platform/concepts/alert) when a threshold rule is crossed. The Integrations tab in Account settings lists every event and the moment it fires. ## What a message says Each message has a title, such as "Agent instance failed" or "Alert raised - Critical", and a sentence naming what was involved: the agent, its version, the environment, and the instance, as far as the event has them. Below that, a short list of details always ends with who acted, the account, and the time. The actor is the person's name when they made the change in the web app, "API token" when a call made it through the API, and "Prefactor" when Prefactor did it itself, as it does when a threshold rule raises an alert. Most messages also carry a **View in Prefactor** button that opens the agent, version, instance, or settings tab the event is about. The agent-deleted message has no button, because the page no longer exists. Messages carry names, identifiers, and timing. A few carry a little more: the email address and role of a user who was invited or added, the scope of a new API token (never the token itself), and the reason someone gave when terminating an instance. They never carry span content or alert payloads. Events about an agent are skipped for the sample agents Prefactor creates for demos, so a demo can't fill your channel. The first-started event fires once per agent, the first time any instance of it starts. ## What to expect from delivery Prefactor queues each notification and sends it to Slack in the background, so the action that caused it never waits on Slack. If Slack is briefly unavailable or slow, Prefactor retries. If Slack rejects the webhook outright, for example because someone deleted it, Prefactor stops trying for that message and the notifications stop until you save a working URL. Delivery is at least once. Slack's incoming webhooks have no way to deduplicate, so in rare cases a message can arrive twice. Prefactor treats the webhook URL as a secret. Once you save it, the app and the API show only that it is configured, never the URL. Prefactor accepts only Slack webhook addresses, which are HTTPS URLs on `hooks.slack.com`. ## Further reading - [Account page › Integrations tab](/admin-ui/account/integrations) — connect a webhook, choose events, and send a test message. - [Alert](/platform/concepts/alert) — the alerts that the alert events announce, and the threshold rules that raise them. - [Account](/platform/concepts/account) — the boundary every notification is scoped to.