A deployment fails, a pod stays unhealthy, a certificate is about to expire, an upgrade is due: Clusterward reports it via webhook, Slack, Teams or email. Once per event, with an all-clear.
Notifications are per-workspace channels that receive selected events from operations: a webhook with a JSON envelope or in Slack and Teams format, or an email address. Event sources are deployments, onboarding runs, imports, add-on installations and two watchers: one observes pods per cluster and reports only transitions, the other checks certificates daily. Every notification lands in a queue, is delivered with retries, signed with HMAC and built without secrets.
A deployment, a run or a watcher produces exactly one message per channel and event.
The content is built from a whitelist of fields; error texts are scrubbed of credentials.
The message waits as a row, independent of whatever triggered it.
Webhook or SMTP, signed, with backoff from seconds to minutes.
Last delivery and last error are shown on the channel.
What matters is not the number of alerts, but whether each one calls for action.
Where your team already reads – with the way to the cause.
A webhook receives a JSON envelope; Slack and Teams URLs are detected and get a text message. https only, with a signature when a secret is set.
Delivery via the platform’s SMTP server to any address, without mail infrastructure of your own.
Emails come with a logo, a colored status line, the details as a table and a button to the right page, in the mail client’s dark mode too. Sender, subject and footer name your workspace’s domain and the operator’s company details – a plain-text version is always included.
The message about a failed deployment links to the service’s logs; for a crash, to the previous run.
Pods, sites, certificates and versions – reported when it matters.
A pod is only flagged once it shows up in two consecutive snapshots. One message per episode, one all-clear when it recovers.
Uptime checks test a service’s domains from the outside. After two consecutive failures, a message goes out; after the first success, the all-clear.
Daily and shortly after startup: managed wildcards are renewed, and every certificate with less than 14 days left or without Ready status is reported, once per day.
New Kubernetes versions and add-on versions from the catalog appear once per version, not on every run.
Suspicious sign-ins and rotations, without giving away secrets themselves.
Admins find out when an address has been blocked after too many failed attempts or an account has been locked. Users get an email when their account is signed in from a new address.
A new version in Secret Manager is reported, a deleted secret once – before the next deploy fails because of it.
Content is built from whitelists, error texts are scrubbed, and a message with a field that looks like a secret is discarded instead of sent.
One row per channel and event; creating it can never make a deployment fail.
Retries from seconds to minutes; a permanent rejection ends delivery immediately.
X-Operator-Signature over the body, verifiable on your side.
Platform-wide mail delivery without a cloud SDK.
Each channel subscribes to its own selection. A Slack channel for deployments, an email address for certificates.
| Event | Source | Meaning |
|---|---|---|
| deployment.failed / healthy | Deployments | Rollout failed or healthy |
| onboarding.failed / succeeded | Tenant pipelines | Onboarding run failed or completed |
| import.failed | Database and bucket import | An import failed |
| pods.attention / recovered | Pod watcher | Pods flagged or healthy again |
| certificate.expiring | Certificate watcher | Less than 14 days left or not ready |
| addon.failed / upgraded / upgrade_available | Add-ons | Installation failed, upgrade completed, new version in the catalog |
| volume.snapshot.failed | Volumes | A scheduled snapshot failed |
| cluster.upgrade_available / finished / failed | Cluster updates | New Kubernetes version, upgrade finished or failed |
| secret.rotated / secret.missing | Secrets | New version in Secret Manager or secret deleted |
| auth.ip_blocked / auth.account_locked | Sign-in | Address blocked after failed attempts, or account locked |
| uptime.down / recovered | Uptime checks | Site unreachable or reachable again |
Most events come from Deployments and Tenant pipelines; the certificate watcher belongs to DNS & certificates.
Which users may create channels is governed by their role in the Users area, described under Security & access.
Uptime checks, resource usage and logs on the service are covered in Logs & monitoring.
Git, container image or Helm chart – rolled out with a health check.
Go to DeploymentsKubernetes version, node pools and add-ons from the cockpit.
Go to Cluster updatesCloudflare zones, automatic records, managed wildcard certificates.
Go to DNS & certificatesCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionWe connect your Slack or Teams channel, send a test message and trigger a real deployment event.
