Notifications

Tessera can notify a chat when a user submits a just-in-time access request, with a link back to the console to approve, and when something happens that a person should go and look at. Telegram is supported today; configure it under Settings → Integrations → Notifications.

Set up Telegram

Create a bot with @BotFather and copy its token.
Find the chat ID of the group or channel to notify.
In Tessera, paste the bot token and chat ID.
Click Send test — a successful test verifies the connection and turns notifications on.

Access requests

When a request is created, the message includes who requested it, the target, the requested mode and duration, and the reason, plus a link to the Requests page for approval. Links use your controller’s public URL. Approvals and refusals are sent too.

Security alerts

The same chat carries the events below. They are not configured separately: setting up the chat is the configuration.

Alert	Raised when	Sent at most
Repeated failed sign-ins	An account or a source address hits the sign-in rate limit	Once per address per 10 minutes
Management authority granted	Somebody gains administrator, or any of the four management permissions	Every time
Primary administrator transferred	The break-glass account moves	Every time
Audit capture changed Audit export changed	Somebody changes what the audit log records, or where it is shipped	Every time
Read-only policy changed Database policy changed Sign-in methods changed	A policy that applies to live sessions is rewritten	Once per editor per 5 minutes
Read-only policy hit repeatedly	The same person is refused five times against the same target	Once per person and target per 10 minutes
Audit chain verification failed	A chain verification finds a problem	Once an hour

Three things are deliberately true of that list.

It is short. Alerting on everything the audit log marks as a warning would include every refused connection and every blocked command, which arrive at the rate of the busiest session in the estate. A channel that pings all day is a channel nobody reads, so the set is the events where somebody should go and look at something.

Repetition is collapsed. Each alert carries a window inside which the same thing is reported once, and the two that describe a pattern rather than an event, repeated failed sign-ins and repeated read-only refusals, only arrive once the pattern is there. The message says how many occurrences it covers.

Only a grant is announced, not a revocation. Authority being taken away is in the audit log and in the access review; it is not worth interrupting anybody for.

The alerts read the audit log itself, which has one consequence worth knowing: an event that audit capture is switched off for is not announced either. That is why changing audit capture is on the list, and why it has no window.

Alerts raised are counted in tessera_security_alerts_total, labelled by the event that raised them. See Monitoring.

Other channels

The notifier is built around a channel interface, so more channels can be added without changing the request flow.