Sources and actions

Every notification channel listens to one or more sources. A source is a category of platform event (approvals, audits, service provisioning, and so on). Each source produces actions: the specific operations that trigger a notification, such as deployment:create or audit:log.

When you create a notification channel, you choose which sources it listens to. You can then use filters to narrow down to specific actions within those sources.

What is a source?

A source groups related platform events under a single label. When you set "source": ["audit"] on a channel, that channel receives every audit event that matches its NRN and filters.

You can assign multiple sources to a single channel (for example, "source": ["approval", "audit"]) or create separate channels per source. Separate channels are easier to manage when each source needs different filters, destinations, or teams.

tip

Start with one source per channel. It's simpler to reason about what each channel does and easier to troubleshoot when notifications don't arrive as expected.

Source reference

Source	What it tracks	Common actions	Typical channels
approval	Approval requests for deployments, scopes, and parameters	deployment:create, scope:stop, scope:delete, parameter:read-secrets	Slack, HTTP
service	Service provisioning actions triggered by scope or service specifications	service:action:create	Agent, GitHub, GitLab, Azure
audit	API activity log for every create, update, or delete on any platform entity	audit:log	HTTP
alert	Platform alerts and monitoring events		Slack, HTTP
entity	Entity lifecycle hooks that run logic before or after entities are created, updated, or deleted	application:create, scope:create, deployment:create	HTTP, Agent
telemetry	Logs, metrics, and instance data from your applications	log:read, metric:data, metric:list, instance:data	Agent
parameters	Parameter lifecycle events: stores, deletes, reads, and change notifications	parameter:store, parameter:delete, parameter:retrieve, parameter:notify, parameter:read-secrets	Slack, HTTP

Action reference

Actions are the specific operations within a source that trigger notifications. Use them in filters to narrow which events reach a channel.

Deployment and scope actions

Track the full lifecycle of deployments and scopes — from creation and updates to stops, deletes, and recreations. Useful for triggering approval flows or alerting on destructive operations.

# Alert when a scope is stopped or deleted
"filters": {
  "action": { "$in": ["scope:stop", "scope:delete"] }
}

Application and entity actions

Track organizational entities such as accounts, namespaces, applications, target groups, and permission grants. Useful for auditing onboarding flows or monitoring access changes across the platform.

# Notify when a new application is onboarded
"filters": {
  "action": "application:create"
}

Service actions

Track service provisioning actions triggered by scope or service specifications — for example, when infrastructure is being created or updated via an external provider.

# Trigger a pipeline on every service provisioning action
"filters": {
  "action": "service:action:create"
}

Parameter actions

Track the full parameter lifecycle: stores, deletes, retrievals, and secret reads. Useful for change management, compliance auditing, or alerting on sensitive secret access.

# Notify when a secret parameter is read
"filters": {
  "action": "parameter:read-secrets"
}

Telemetry and monitoring actions

Track log reads, metric data, instance updates, and monitoring events from your running applications. Typically routed to an agent for custom processing.

# Capture metric and log events for custom processing
"filters": {
  "action": { "$in": ["metric:data", "log:read"] }
}

Audit filterable fields

Audit events don't use a discrete action list. Instead, filter by any combination of these fields to track exactly what you need:

Field	Type	Description
entity	string	The type of entity affected (application, scope, deployment, …)
method	string	HTTP method of the operation: GET, POST, PATCH, DELETE
status	number	HTTP status code of the operation
entity_context.<field>	any	Any field within the entity context object, accessed via dot notation (e.g. entity_context.account_id)
url	string	The API path that was called
user_type	string	Who triggered the event: user or service_account

Choosing the right source

You want to...	Use source	Example
Track who changed what and when across the platform	audit	Route audit:log events to an HTTP webhook for your SIEM
Get approval requests in Slack	approval	Send deployment:create approvals to a Slack channel
Trigger infrastructure provisioning pipelines	service	Route service:action:create to a GitHub Actions workflow
Run custom logic before or after entity lifecycle events	entity	Send scope:create events to an HTTP endpoint for pre-validation. See Entity hooks
Stream logs and metrics to a custom provider	telemetry	Route metric:data and log:read to your agent. See Telemetry
Get notified when parameters change	parameters	Send parameter:store events to Slack so teams know when config changes
Forward platform alerts to your on-call tools	alert	Route alerts to a Slack channel or PagerDuty webhook

Next steps

• Create a notification channel
• Apply filters to route specific events
• Manage existing channels
• Inspect event payloads