Notifications & escalation

Sencai has several distinct ways to keep you informed, layered rather than unified into one settings screen: an in-app notification center, email and browser-push preferences, organization-level escalation policies, and outbound webhooks. This page covers each briefly and links to the deeper reference for webhooks.

In-app notification center

Notifications (/gravity/notifications, with history at /gravity/notifications/history) is the bell icon’s full view - platform events grouped into Cloud, Incidents, Approvals, Billing, Security, Git, and System categories, with filter chips to narrow the list. Each notification shows a title, detail text, how long ago it happened, and - where relevant - a link to the resource it’s about.

Unread notifications can be marked read individually or all at once; read notifications move to History, which you can clear. There’s no per-category subscription toggle for this in-app list itself - what you see here reflects platform activity for your organization, not a feed you opt in or out of.

Email preferences

Settings → Email Notifications (/gravity/settings/notifications) controls what Sencai emails you:

Category	Can you turn it off?
Transactional (billing receipts, security alerts, account notices)	No - always on
Product Updates	Yes
Marketing	Yes
Digest (periodic summary of your organization’s activity)	Yes

Every non-transactional email also includes a one-click unsubscribe link that opts you out of that category instantly, no login required - this settings page always reflects the current state regardless of which way you changed it.

Browser notifications

The same settings page lets you enable browser (Web Push) notifications - payment failures, monitoring alerts, and cloud-instance provisioning failures, even when Sencai isn’t open in a tab - and, once enabled, optionally filter down to specific event types instead of receiving every one.

Escalation policies (PagerDuty / Opsgenie)

Settings → Escalation (/gravity/settings/escalation) lets an Admin or Owner configure PagerDuty or Opsgenie policies - a name, provider, routing key or API key (stored encrypted and never shown again after creation), and whether to escalate critical incidents only or medium severity and up.

Caution

Configuring a policy here stores it, but actual delivery to PagerDuty or Opsgenie isn’t active in this environment - there’s currently no way to connect a real PagerDuty/Opsgenie account, so nothing is sent to either provider when an incident is created. Fallback delivery by email isn’t active either. If on-call paging is something you need today, treat Incidents and the in-app notification center as your primary channel, and ask your account team about escalation delivery.

Slack and Microsoft Teams

Separately from escalation policies, your organization can configure Slack or Microsoft Teams incoming-webhook channels under organization settings to receive a smaller set of platform notifications (payment failures, trial ending soon, instance provisioning failures, and firing alerts). This is a distinct mechanism from both escalation policies and customer webhooks below - it’s aimed at a team channel, not an on-call rotation or your own systems.

Webhooks

Outbound webhooks let your own systems receive platform events directly, independent of any Sencai UI. From Settings → Webhooks you register an endpoint URL and choose which events it subscribes to, and the platform signs every delivery with HMAC-SHA256 so you can verify it came from Sencai. Each webhook also has its own delivery log - status, attempt count, and timestamp for recent deliveries - plus a manual Test action to confirm your endpoint is reachable before relying on it.

Caution

Registering an endpoint and choosing its events works, but the platform does not yet call your endpoint when those events actually happen - only the Test action generates a delivery. Do not build a workflow that depends on receiving them yet. See Webhooks for the current state.

Note

Today’s webhook event types cover cloud-instance and organization-membership changes (provisioning succeeded/failed, configuration drift detected, budget threshold reached, member added/removed) - not incidents or firing alerts specifically. For those, the in-app notification center and email/browser preferences above are the more complete channels right now.

See API: Webhooks for the full event catalog, payload shape, and signature verification details - this page intentionally doesn’t duplicate that reference.

What’s next

• API: Webhooks - full webhook reference: events, payloads, signature verification
• Incidents - the source of most operational notifications
• Monitoring - where alert thresholds that feed notifications are defined
• Identity: Account security - notifications tied to your own account, as opposed to organization-wide activity