Notifications
A vs B sends you two kinds of notifications. The first: a scheduled experiment or flag firing, or failing to fire. The second: errors showing up in a running experiment's code. Notifications appear in two places: the bell icon at the top of every authenticated page, and a transactional email.
The bell dropdown
The bell sits in the top bar, before the help dropdown and your avatar. A red badge with the unread count appears whenever there is at least one unread notification.
- Clicking the bell opens the panel and refreshes the list. There is no realtime push in v1: the badge checks for new notifications every five minutes while the tab is in view, and opening the panel forces a fresh read.
- Clicking a notification marks it read and navigates to the linked resource (the experiment or flag the event applies to).
- Mark all read in the header clears every unread notification for your account in one call.
For a scheduling event, the person who scheduled the experiment or flag (not the whole team) gets the transactional email. For a code-error alert, A vs B emails the person who launched the experiment. If no one is on record as the launcher, it emails an admin on the project instead. Emails include the resource name, the project, and a direct link back to the dashboard. A vs B sends all its outbound email, account emails included, through Cloudflare Email Sending.
v1 sends both the in-app and email channels for every event in the table below. Per-event mute settings are tracked under a future iteration of the notifications surface.
Support ticket emails
When you open a support ticket from the Help menu, A vs B emails you a confirmation with the ticket's number. You get another email when the support team replies to you, quoting the reply, and when support changes the ticket's status, for example to Resolved. Notes the support team writes for each other are never sent. Each email has a View ticket button that opens the ticket in A vs B.
On the ticket page you can close the ticket yourself once you no longer need help: click Close ticket under Details. If the problem comes back, or support marked it resolved too soon, click Reopen ticket. Closing or reopening a ticket yourself sends no email, and both show in the ticket's Activity list, along with every file attached to the ticket or a reply.
Notification types
| Event | When it fires | Resource |
|---|---|---|
EXPERIMENT_SCHEDULED_LAUNCH_FIRED | A scheduled experiment launches automatically. | Experiment |
EXPERIMENT_SCHEDULED_END_FIRED | A running experiment is auto-paused at its scheduled end. | Experiment |
EXPERIMENT_SCHEDULE_MISSED | The scheduled moment was more than 60 minutes in the past when the worker came online, so the schedule did not fire. | Experiment |
EXPERIMENT_SCHEDULE_FAILED | The schedule could not fire due to an error (e.g. revoked permissions in strict mode). | Experiment |
EXPERIMENT_CODE_ERROR_DETECTED | A running experiment's code starts throwing errors, or A vs B auto-pauses the experiment because of them. | Experiment |
FLAG_SCHEDULED_ENABLE_FIRED | A scheduled flag enable on a specific environment fired. | Flag environment |
FLAG_SCHEDULED_DISABLE_FIRED | A scheduled flag disable on a specific environment fired. | Flag environment |
FLAG_SCHEDULE_MISSED | Missed flag schedule, same window as experiments. | Flag environment |
FLAG_SCHEDULE_FAILED | Flag schedule failed at fire time. | Flag environment |
Programmatic access
Notifications are also available through the REST API:
GET /api/notifications: list, paginated.POST /api/notifications/{id}/read: mark a single notification read.POST /api/notifications/read-all: mark every unread notification for the calling user read.
All three endpoints are scoped to the authenticated user; there is no cross-user read.