Skip to main content
Ryvn sends real-time notifications about installation health, job execution, and deployment status through Slack. Get instant updates when issues occur so you can respond quickly.

​
Notification types

Ryvn automatically notifies you when:
  • Installations enter crash loops
  • Out-of-memory (OOM) errors occur
  • Non-zero exit codes are detected
  • Installations become unhealthy
  • Jobs fail to execute
  • Builds or deploys fail
  • Image pulls fail

​
Notification destinations

By default, notifications are delivered to Slack. Configure your Slack workspace to receive notifications in your chosen channels:
  • Set up dedicated channels for different environments
  • Filter notifications by type
Want notifications in other destinations like email or MS Teams? Contact us to discuss additional integration options.

​
Connecting to Slack

To connect your Slack workspace:
  1. Go to Settings
  2. Navigate to the Notifications section
  3. Click Connect Slack

​
Maintenance subscriptions

In Settings → Notifications, enable one or both opt-in maintenance subscriptions for your Slack destination: New Slack destinations default to failed deployments (installation.task.failed) and failed Git syncs (gitsync.sync.failed). Reconnecting Slack preserves saved subscriptions.
Subscribing does not enable notification production. The corresponding producers must also be enabled in the running deployment.

​
Configuring through the API

Read subscriptions with GET /v1/orgs/{orgId}/notifications/destinations. Replace them with PATCH /v1/orgs/{orgId}/notifications/destination/{destinationId}/subscriptions, including existing keys you want to keep. For example, enable both choices while retaining failed-deployment notices:
Omit a key to unsubscribe. Unknown keys are rejected without changing saved preferences.

​
Exclusion lifecycle notices

  • Scheduled: a future exclusion.
  • Activated: an exclusion starts. Already-active exclusions start here, without a scheduled notice.
  • Changed: a material name, description, start, or end edit. No-op edits and bookkeeping do not notify; an edit during a phase transition produces one notice.
  • Ended: expiry or early removal, distinguished in the message. Pin replacement ends the old exclusion and starts a new lifecycle. This is not deployment success; other controls may still block updates.
Each scheduled, activated, or ended phase is handled at most once per exclusion, across eligible destinations. A first subscriber can receive an unhandled current scheduled/active phase, but later subscribers do not replay handled phases. Later phases and material changes remain eligible. Endings without subscribers are dropped. Expiry requires an earlier queued phase; early removal does not. Queuing a changed notice cancels superseded pending scheduled/activated notices in the same transaction. For exclusions that still exist, installation-scoped notices include installation and environment names; environment-wide notices name the environment. A configured dashboard URL adds an escaped scope link. Removal notices use recorded facts and the current parent name, or scope/ID if gone. Deleting an installation or service does not itself produce an ended notice.

​
Deferred-update notices

Coverage is maintenance exclusions and version pins, not every blocked update. Existing evidence must prove the pending revision/target and a policy that currently blocks it. Issue text, blocked status, timestamps, ordinary closed maintenance windows, or unrelated constraints alone do not qualify. Environment exclusions not enforced by the task gate are skipped; notifications do not change deployment eligibility. Initial-install, release, configuration, and secret updates qualify only with proven evidence. Fresh configuration or secret revisions, including releases with an unproven new revision, may receive no notice. Release-only pins allow configuration and secret updates. Pending or running deployments, including stuck ones, can withhold notices. Deduplication is per installation and validated revision/target pair, not per action. A continuously blocked pair does not re-notify; a new pair is eligible. Confirmed clearance of maintenance blockers or a proven matching accepted update resets deduplication. Uncertain evidence preserves it, including when a later refusal makes acceptance unprovable. A real reset may therefore be missed. There are no reminders, recovery notices, or cross-installation grouping. Messages name the installation, target version, configuration revision, and a bounded list of applicable exclusions or pins with an overflow count. They contain no configuration values or secrets.

​
Best-effort delivery and limitations

Delivery is best effort, not guaranteed:
  • Scan delays: the lifecycle watcher scans one page using an in-memory cursor: up to 200 candidates every 30 seconds across organizations, including handled scheduled/active exclusions. With 10,000 stable candidates, revisits take about 25.5 minutes, including empty wraparound and excluding processing time. Short exclusions can miss activation and natural expiry if no earlier phase was queued.
  • Missed observations: short deferrals may be missed; intermediate revisions can collapse into the latest state. External-input changes without a new revision/target do not trigger another notice. Without subscribers, an unhandled current deferral can remain eligible, but handled occurrences do not replay. Undeliverable destinations may be dropped.
  • Delivery checks: obsolete notices can be cancelled. A missing environment makes a live installation notice stale; transient read failures retry. Uncertain deferred evidence sends nothing and retries within the shared budget: three total attempts by default, including webhook failures. Exhaustion preserves deduplication, without automatic re-enqueue when evidence recovers. With five-second polling and little backlog, attempts can exhaust in about ten seconds from the first evaluation. Reads are not a single snapshot; completed or in-flight sends cannot be recalled.
  • Slack rate limits: the shared worker processes serially, up to 50 attempts every five seconds across organizations and notification types. This is not a per-channel rate limit. Monitor queue age, delivery failures, and HTTP 429s.