Notifications
ComputeSphere fans every notable event out to the channels you've turned on, filtered by the categories you care about. Two switches per category — do I want it? and where do I want it? — control everything.
Each event maps to a category. The category must be on, and the channel must be on, for the notification to deliver.
For a notification to reach you, both must be on: the event's category, and at least one channel.
Event categories
Every event lands in exactly one of five categories. Toggle a category off and you'll stop receiving events of that kind on every channel.
| Category | What lands here |
|---|---|
| Deployment | A service started, finished, failed, or rolled back. Use this if you want to know when your deploys go red. |
| Billing | New invoices, plan changes, monthly statements. |
| Payment | Upcoming-charge reminders and failed payment attempts. |
| Activity | Significant account activity — members added or removed, role changes, API token created. |
| Invites | Account and team invitations sent to you or accepted by someone you invited. |
Channels
You can route notifications to any combination of three channels. Each has its own enable switch.
| Channel | Where it goes | Config |
|---|---|---|
| In-app | The bell icon in the console. | None — just toggle on. |
| A list of email addresses you specify. | One or more emails. | |
| Webhook | An HTTPS endpoint you control, including Slack and Microsoft Teams incoming-webhook URLs. | URL + content type + optional secret token. |
Webhooks
A webhook delivery is a POST request to a URL you provide. ComputeSphere supports two payload formats, plus an optional shared secret your endpoint can use to verify the request came from us.
| Field | Purpose |
|---|---|
url | The endpoint to POST to. HTTPS only. Slack incoming-webhook URLs and Microsoft Teams workflow URLs both work here. |
content_type | json (recommended) — structured object — or text — a plain string formatted for chat apps. |
token | Optional shared secret. When set, ComputeSphere sends it in the Authorization: Bearer <token> header so your endpoint can drop unauthenticated requests. Leave blank for Slack and Teams webhooks (they don't validate auth headers). |
You can configure multiple webhook destinations. Each gets every event that matches the categories you've enabled.
For chat tools, set content_type: text and paste your incoming-webhook URL — the message renders as a normal chat post. Slack: see Incoming Webhooks. Microsoft Teams: use the Workflows app to generate a webhook URL.
Manage notifications
- Open Settings → Notifications.
- Under Categories, toggle the event kinds you want to receive.
- Under Channels, enable In-app, Email, or Webhooks — or all three.
- For email: add one or more email addresses.
- For webhooks: click Add webhook, paste the URL, pick a content type, and (optionally) set a verification token.
- Click Update.
To read or dismiss in-app notifications, click the bell icon in the top bar.
Honest limits
- Settings are per user, not per account. Each user manages their own categories, emails, and webhooks. Two users on the same account can have different preferences.
- No per-service routing. Webhooks fire for every event in an enabled category across the account; you can't (yet) route a project's deployment events to one URL and another project's to a different URL.
- No retry surface. A 5xx response from your webhook isn't queued for retry. Make sure your endpoint is highly available, or accept best-effort delivery.
- In-app retention. Read notifications are kept for 90 days, then auto-removed. Dismissed notifications are removed immediately.