Event Notifications Is Now Generally Available: Get Alerted to What Matters, Automate the Rest

Vendor teams shouldn't have to watch dashboards to know what's happening

If you're shipping software to customer-managed environments, you already know the challenge: your customers install and operate your application in environments you don't control, and visibility into what's happening across those deployments is critical. When a customer's license is about to expire, when an instance goes unhealthy, when a support bundle gets uploaded at 2 AM, your team needs to know.

Until recently, the options for getting proactively notified about these events on the Replicated Platform were limited. The original Instance Notifications system covered a narrow set of instance-level events with basic email or single-channel slack delivery. Teams that needed broader coverage or more flexible routing had to build their own polling and alerting on top of the Vendor API.

Today, we're excited to announce that Event Notifications is now generally available for all vendors. Event Notifications is a complete rethinking of how vendor teams subscribe to, filter, and act on platform events. It replaces the original Instance Notifications with a system that's broader in scope, more precise in targeting, and designed to integrate directly into the tools and workflows your team already uses.

What you can do with Event Notifications

Event Notifications gives you access to over 20 event types organized across six categories:

• Releases and channels: release promoted, release build failed
• Customers: customer created, customer updated, license expiring, customer archived
• Application instances: instance created, instance ready, upgrade completed, state duration, version behind, custom metric thresholds
• Support bundles: uploaded, analyzed
• Enterprise Portal: invite sent, access granted, user joined

Each notification subscription lets you combine multiple event types with granular filters to ensure the right people on your team are alerted to the right events. Filters use AND logic within an event (all conditions must match) and OR logic for multi-value selections (e.g., "Paid" OR "Trial" license types), giving you fine-grained control without complexity.

Concrete examples: how vendors are using notifications today

Here are some of the patterns we're already seeing across our early adopters:

Stay on top of release operations

A DevOps lead sets up a webhook notification for [.inline]release.promoted[.inline] events, routed to a dedicated #releases Slack channel. Every time a new version is promoted to the Stable channel, the team gets a message with the release version and channel context, no manual checking required.

With the new [.inline]release.build_failed[.inline] event, teams can also get alerted the moment a build fails after promotion. This matters beyond air gap bundles: Enterprise Portal docs, Download Portal release lists, install instructions, and Embedded Cluster installs can all be affected by a failed build. Without this notification, the only way to discover the failure was manually checking the release history page.

Automate customer onboarding notifications

A Customer Success team uses the Replicated CLI to script notification setup as part of their customer creation and onboarding pipeline. After creating a new customer and assigning a channel, they run:

[.inline]replicated notification subscription create --file config.json[.inline]

The config automatically creates a subscription that alerts a team Slack channel whenever the new customer's instance falls behind by 3+ versions:

[.inline]{[.inline]
   [.inline]"name": "Upgrade compliance - Acme Corp",[.inline]
   [.inline]"eventConfigs": [[.inline]
      [.inline]{[.inline]
         [.inline]"eventType": "instance.version_behind",[.inline]
         [.inline]"filters": {[.inline]
            [.inline]"versionsBehind": "3",[.inline]
            [.inline]"customerId": "<newly-created-customer-id>"[.inline]
         [.inline]}[.inline]
      [.inline]}[.inline]
   [.inline]],[.inline]
   [.inline]"isEnabled": true,[.inline]
   [.inline]"webhookUrl": "https://hooks.slack.com/services/T00/B00/XXXX"[.inline]
[.inline]}[.inline]

Because notification subscriptions are now fully manageable from the CLI ([.inline]create[.inline], [.inline]update[.inline], [.inline]list[.inline], [.inline]delete[.inline]), teams can template configs in version control and enforce consistency across hundreds of customers programmatically.

Proactively manage license renewals

A Sales Manager subscribes to [.inline]customer.license_expiring[.inline] events filtered to Trial license types. When a trial customer's license nears expiration, the alert fires to email, giving the sales team a heads-up to engage before the customer goes dark. Combined with [.inline]customer.created[.inline] and install validation events like [.inline]instance.ready[.inline], teams can build notification-driven workflows that track the full customer journey from trial signup through deployment to renewal. For a walkthrough of how to wire these events into a revenue operations pipeline, see Tracking the Customer Lifecycle from Trial Signup to Revenue Recognition.

Cut through the noise with instance tag filters and muting

A vendor managing multiple instances per customer uses instance tag filters to scope health alerts to production environments only. By adding a tag filter with [.inline]environment equals Production[.inline], they avoid getting paged for every dev and staging instance that drifts.

When a known-noisy instance is expected to be unhealthy (e.g., during a planned maintenance window), the team mutes it on the subscription for 7 or 30 days, or indefinitely. Mutes are cluster-aware, so snapshot/restore scenarios won't accidentally silence alerts for the wrong cluster. Active mutes are visible from the notification History tab with a per-subscription badge.

Get your support engineers to bundles faster

When a customer uploads a support bundle, time matters. A Support Engineering lead subscribes to [.inline]support.bundle.uploaded[.inline] events filtered to paid customers on the Stable channel, with a webhook routed to a [.inline]#support-triage[.inline] Slack channel. The webhook payload includes the bundle ID, customer name, app, channel, and license type, giving the on-call engineer enough context to prioritize before even opening the bundle.

Once the bundle is analyzed, a second subscription on [.inline]support.bundle.analyzed[.inline] can trigger a follow-up notification with analysis results, enabling teams to build automated triage workflows that route bundles based on severity or content. For a deeper look at how to build an end-to-end support bundle workflow powered by event notifications, see Building a Support Bundle Workflow That Meets Your Engineers Where They Already Work.

Getting started

Event Notifications is available to all Replicated customers. To create your first notification:

1. Navigate to Vendor Portal > Notifications > New Notification
2. Select the event types you care about
3. Apply filters to target the right scope
4. Choose email or webhook delivery
5. Send a test to confirm your configuration
6. Enable the subscription

For teams looking to automate, the Replicated CLI supports full notification subscription management.

See the Event Notifications documentation for the complete reference, including the full list of event types, filter options, webhook payload formats, and RBAC permissions.

If you'd like a walkthrough from someone on our team, reach out to your account manager. We're happy to help you design a notification strategy that fits your team's workflow.