Notifications and alerts
Events shows what happens with your customers as it happens, and the alerts your notifications raise. It has three tabs: Alerts, Events, and Notifications.
- A notification says when to raise an alert, for which customers, and whether to email.
- An alert is one time it fired. New alerts show as a count on Events in the left rail.
Making a notification
On Notifications, choose New notification. Notifications start on Pay as you go, and making and changing them needs the Change customers permission.
When it fires:
| When | |
|---|---|
| A customer event, as it happens | Any event your engines raise for a customer (below), from every server running your app, and from changes made to customers in the app |
| A payment waits for approval | A charge for a customer who needs approval first |
| A payment succeeds / fails | A charge's outcome |
| A payment needs the customer | Ex. 3D Secure |
| A group invoice is made | An account's invoice for a period closes (an org with its users, or a customer on its own) |
| An account's invoice is overdue | An account's invoice is unpaid past its due date (once an invoice) |
| A contract's renewal or end is coming up, or it renews | A contract is a month from its notice deadline (or its end), or it renews |
For customer events, choose the Event (or Any of these):
- Usage past a soft limit (billed)
- A call denied at a hard limit
- A call denied by a cap
- Usage within a limit
- A meter starts a new period
- A call held back by a rate limit
- A cap crosses its threshold
- A tracked feature is checked
- An entitlement is given to a customer, taken from a customer, or restored
- A customer changes plan
Then:
- For: every customer, or a segment.
- Only when (optional, Stof): a condition on the event, which sees
type(the event's name) andevent(its data, withevent.customer). Ex.event.entitlement == 'chat' && event.remaining < 1000, orevent.event_data?.workflow == 'support'for the metadata your app passed with the call. The events reference lists every event's fields. - Email: no email, the team (the workspace's members), or a list of addresses.
- Event name in your app (optional): your engines raise the alert as an event of this name too, so your own code can react (Ex. show a banner).
Turn a notification off with its switch instead of deleting it.
"Usage within a limit" fires on every metered call. Narrow it with a segment or a condition with a threshold, or your team gets an alert per call. For a one-time warning (Ex. at 80% of a budget), a cap that only records and "A cap crosses its threshold" fire once when it's crossed.
Alerts
Alerts lists what fired: the notification, the event, and the customer. Filter by New, Seen, Resolved, or All, mark alerts seen (or Mark all seen), and Resolve the ones you've handled. Click one to see the event's data. Any member can do this.
The event log
Events lists every event for the workspace, newest first and live: limits, overages, payments, publishes, plan changes, and edits in the app. Filter by kind or by customer ID, and expand one to see its details.
In your policy
Notifications on engine events (limits, overage, caps, rate limits, resets, tracked features) reach your connected engines with the policy when you save them, and run there next to your own handlers. Plan changes, given, taken, and restored entitlements, and payments are matched in Cloud, so Event name in your app doesn't fire in your engines for those. You can also write notifications in the policy itself: see Notifications in the engine reference.