Who gets told when you publish, and how
Subscribers & notifications
Anyone can subscribe from your public page. They confirm by email, choose the language they want updates in, choose which services they care about, and are told whenever you publish or update an incident or scheduled maintenance. Your own team can have the same events delivered to Discord, Microsoft Teams or Telegram.
Dashboard → Notifications. Subscribers lists the people; Email controls who the mail comes from; Discord, Microsoft Teams and Telegram are the chat destinations; Templates is the wording. All of it is included in the Subscriber updates capability.
Only Account owners and admins can view subscriber addresses and subscription details. Operators and viewers can still read the safe notification settings available to their role.
What gets sent
A new incident, each update on it, its resolution, the first publication of its postmortem, and each scheduled maintenance with its reminder. Nothing else: no digests, no marketing. Every email is in the subscriber's own chosen language and carries a one-click unsubscribe link.
An update you mark publish silently is not sent (see Incidents). Auto-opened incidents email subscribers too, which is the reason for the fifteen-minute gate described there.
Choosing which services
When somebody subscribes they choose all components or specific components. A page-wide incident reaches everyone; an incident on one service reaches the people who chose it. Every email carries a Choose which services link in its footer, so a subscriber can change their mind without unsubscribing, and the roster shows what each person hears about.
The roster
Notifications → Subscribers lists everyone with their status (confirmed or still pending), language, and scope. Owners and admins can export the list as CSV: email, status, language, scope, services, and when they confirmed and subscribed. Because it is a list of your customers' addresses, the export asks you to confirm it is you by clicking a link we email you first.
How many you can have
When InBrief sends the email, the hosted subscriber allowance shown in Billing applies. Reaching it stops new people subscribing; it never drops anyone you already have.
Connect your own Resend or SendGrid account and the cap comes off entirely. It is removed rather than raised: send to as many people as your provider allows. The cap only ever existed because we pay for the delivery; the moment notifications go out through your own sending account, you are paying that bill, and there is no reason for us to limit it.
Sending from your own address
By default, notifications come from us. Notifications → Email lets you send them from your own domain instead, which is worth doing: an outage email from an address your customers already trust is less likely to be filtered, and reinforces that the message is really from you.
| Option | What it takes | Cap |
|---|---|---|
| InBrief | Nothing | Hosted allowance |
| Resend | An API key | Lifted |
| SendGrid | An API key | Lifted |
| SMTP | Host, port, username, password | Hosted allowance still applies |
SMTP keeps the hosted allowance on purpose. The two API providers accept a hundred recipients per call; SMTP opens one connection per recipient, and lifting the cap there would not let you send more, it would let you accumulate subscribers who are never emailed, and find out during an outage.
Whichever you choose, use Send test email before you rely on it, and add the SPF and DKIM records the screen shows so your provider's mail is not marked as forged. An API key is stored once and shown as set afterwards; SMTP fields are re-entered in full each time you save.
Removing your provider later puts you back on the hosted allowance. Subscribers you already have are kept; you simply stop gaining new ones until you are back under it.
Email templates
Notifications → Templates holds the two emails your subscribers read: the incident and maintenance notice, and the subscription confirmation. Each has a reviewed default in every language, and you can rewrite either per language; the Branding and custom domain capability allows editing. Sign-in links and team invitations come from InBrief and cannot be rewritten: an email that asks somebody to sign in has to look the same for everyone, which is what makes a fake one recognisable.
Discord, Microsoft Teams and Telegram
These deliver the same events to a channel your own team watches. Each destination has a name, a language, and a scope (the whole page or particular services), a Send a test button, and can be paused or deleted. Each has its own page with the real screen and the setup steps on the provider's side:
- Discord: a webhook URL from the channel's integrations settings.
- Microsoft Teams: a workflow URL from the Teams Workflows app, with a co-owner and a standard or shared channel.
- Telegram: a bot of your own and a chat id, confirmed with a code the bot posts into the chat.
Saving or deleting a destination asks you to confirm it is you, by clicking a link we email you; the confirmation is good for ten minutes. If a destination fails five times in a row it is paused and the screen says so, so a deleted channel does not silently swallow your next incident. For alerts on named people's phones rather than in a channel, see WhatsApp.
Browser notifications
Browser notifications are built and held behind an operations control, and are not yet released: until the control is switched on for a page, its Get updates panel offers email only. What follows describes how they work once that happens.
Visitors can follow your page from their browser instead of by email, from the same Get updates panel. There is no address to hand over and nothing to unsubscribe from: the browser itself holds the permission, and they can withdraw it from your page or from their browser settings at any time. It has its own allowance, separate from email.
How someone turns it on
They click, their browser asks permission, and they allow it. Nothing is requested when the page merely loads; the prompt only ever follows a click of their own. We then send one silent test notification to confirm their browser can actually be reached; until that comes back, they are not yet subscribed.
They can follow the whole page or pick services, exactly as with email.
Which browsers work
| Browser | Supported |
|---|---|
| Chrome, Edge and other Chromium browsers | Yes, desktop and Android |
| Firefox | Yes |
| Safari on macOS | Yes |
| Safari on iPhone and iPad | No |
iPhone and iPad are excluded deliberately. Safari there only allows notifications for a site the visitor has installed to their home screen, and we would rather offer nothing than offer something that quietly never arrives. On an unsupported browser the option is simply not shown.
What we keep, and for how long
An address is never involved. What is stored is the delivery handle the visitor's own browser issued, held encrypted, plus their language and service choice. You can see how many browsers follow your page, and nothing that identifies one. A subscription ends when the browser's push service reports it gone, after a year with no visit and no delivered notification, or when the page or account is deleted.
If notifications are not arriving
- Nothing was ever offered. The browser is unsupported, or the page is not open over HTTPS. Both hide the option rather than failing later.
- Permission was refused once. Browsers remember a refusal and will not ask again. It has to be cleared in the browser's own site settings for that page; we cannot re-prompt.
- Permission was granted but nothing arrives. The test notification is the check: if it never appeared, the browser is not reachable. A private or guest window, a profile with notifications disabled system-wide, and an OS focus mode all do this.