Event subscriptions

Everything notable that happens in Sluicio — an alert paging someone, a new service entering the catalog, a configuration change — is a domain event. Instead of polling the API for changes, you can have Sluicio push those events to your platform: Azure Event Grid, AWS EventBridge, an n8n workflow, or an internal bus.

Event subscriptions are managed on the Developers page (API & MCP), in the Event subscriptions section. A subscription is:

• a name,
• a scope — a team, or the whole organization,
• one or more event-type filters,
• a destination webhook channel, and
• an enabled toggle.

The destination is an ordinary webhook notification channel — the same channels alerts deliver to, reusing the channel’s payload-format and signing settings. Create a channel per consumer, then point any number of subscriptions at it.

Event vocabulary

Event types are reverse-DNS names: com.sluicio.<entity>.<verb>. They come in two families.

Operational events describe things happening in your integration landscape:

Type	Emitted when
com.sluicio.alert.fired	An alert fires and actually notifies — a firing suppressed by a maintenance window stays silent here too
com.sluicio.alert.resolved	A previously-notified alert resolves
com.sluicio.errors.opened	The error notifier paged for new errors
com.sluicio.service.discovered	A service enters the catalog for the first time

Configuration events are derived mechanically from the audit action vocabulary — every audited mutation emits an event, named after the entity and verb: com.sluicio.integration.created, com.sluicio.alert_rule.updated, com.sluicio.group.member_added, and so on. Anything the audit log would record as an admin action exists as an event type, so the vocabulary grows with the product rather than being hand-curated.

Filters

A subscription’s filters are globs over the type name, and it needs at least one:

• Exact — com.sluicio.alert.fired matches that one type.
• Prefix — a trailing *, as in com.sluicio.integration.*, matches every type under the prefix.
• Everything — a bare * matches all types. It’s allowed, but you have to choose it explicitly — there is no implicit subscribe-to-all.

An event delivers once per subscription even if several filters match it.

Payload formats

The destination channel’s payload format setting decides the shape — exactly as it does for alert webhooks.

A CloudEvents-format channel receives CloudEvents 1.0 structured mode, posted as application/cloudevents+json:

{
  "specversion": "1.0",
  "id": "0d9f2c62-6b1e-4f0a-9a4e-1c7f0b7a3d55",
  "source": "https://sluicio.example.com/",
  "type": "com.sluicio.alert.fired",
  "time": "2026-07-24T12:34:56Z",
  "datacontenttype": "application/json",
  "subject": "6b8a1d74-2f30-4c9e-b1a7-90d5c3e28f11",
  "data": {
    "rule_id": "6b8a1d74-2f30-4c9e-b1a7-90d5c3e28f11",
    "rule_name": "Checkout latency p95",
    "severity": "critical",
    "signal": "metric",
    "service": "payments-eu",
    "instance_id": "c41e77a9-8be0-4d16-9a2f-5f0e6b3d1c84"
  }
}

A default-format channel receives the same fields as canonical flat JSON, with the type under event and no envelope ceremony:

{
  "event": "com.sluicio.alert.fired",
  "id": "0d9f2c62-6b1e-4f0a-9a4e-1c7f0b7a3d55",
  "time": "2026-07-24T12:34:56Z",
  "subject": "6b8a1d74-2f30-4c9e-b1a7-90d5c3e28f11",
  "source": "sluicio",
  "data": {
    "rule_id": "6b8a1d74-2f30-4c9e-b1a7-90d5c3e28f11",
    "rule_name": "Checkout latency p95",
    "severity": "critical",
    "signal": "metric",
    "service": "payments-eu",
    "instance_id": "c41e77a9-8be0-4d16-9a2f-5f0e6b3d1c84"
  }
}

data carries whatever that event type describes, and is deliberately small — enough to route on, not a mirror of the entity. A com.sluicio.service.discovered delivery, for instance, carries just the name:

{
  "event": "com.sluicio.service.discovered",
  "id": "8ad2f501-5b6c-4e77-9c31-2ab7d4e6f099",
  "time": "2026-07-24T12:35:10Z",
  "subject": "payments-eu",
  "source": "sluicio",
  "data": { "service": "payments-eu" }
}

Two fields are worth knowing precisely, because consumers route on them:

• subject identifies the entity the event is about, in that entity’s own terms — the rule ID for alert events, the service name for service events, the target’s ID for configuration events.
• source differs by format: CloudEvents uses the cell’s public base URL (Settings → System → General), falling back to urn:sluicio:cell when no public URL is configured; the flat format always sends the literal sluicio. Use subject and id for routing and dedupe, not source.

Each emission mints one event id, shared across every subscription it delivers to — if the same event reaches your platform over two routes (say a team subscription and an org-wide one), consumers can dedupe on id.

If the channel has a signing secret, HMAC request signing applies to event deliveries exactly as to alert webhooks: verify X-Sluicio-Timestamp and X-Sluicio-Signature to reject tampered or replayed deliveries.

Scoping and permissions

A subscription is team-scoped or org-wide — team-scoped is the primary model:

• A team subscription only receives events about entities the team can see, resolved through the same visibility rules as groups and access policies. Org-administration events — members, groups, settings, tokens and the like — never reach a team subscription, whatever its filters say.
• An org-wide subscription receives everything its filters match, including org-administration events. Creating one takes an org admin.

Team subscriptions are managed by org editors — or, on Enterprise with advanced RBAC, by that team’s own group-editors, so a team can wire its events into its own tooling without an org-level ticket.

Delivery semantics

Delivery is at-least-once: a delivery that fails is retried up to 5 attempts with exponential backoff, and a slow consumer may occasionally see a duplicate — dedupe on the event id. Finished deliveries are kept for inspection and pruned after roughly 3 days.

Events are notifications, not a record

Event subscriptions are best-effort notifications for driving automation. The audit log remains the tamper-evident record of what changed — a subscription is never a compliance substitute.

Worked example: alerts and discoveries into your bus

Say you want alert activity and new-service discoveries flowing into an n8n workflow (the same steps fit an EventBridge API destination or an Event Grid webhook — anything that accepts an HTTPS POST).

1. Create the channel. On Alerts → Notification channels, add a webhook channel pointing at your consumer’s HTTPS endpoint — the n8n Webhook-node URL, or the EventBridge API-destination endpoint. Set a signing secret, and enable the CloudEvents 1.0 format (n8n and EventBridge both consume it directly; leave it off if your consumer wants the flat shape).
2. Create the subscription. On the Developers page, under Event subscriptions, add a subscription: name it, scope it to your team, pick the channel, and add two filters — com.sluicio.alert.* and com.sluicio.service.discovered. Enable it.
3. Fire a test. The next time an alert notifies, the channel receives a com.sluicio.alert.fired event; when a new service first reports telemetry, a com.sluicio.service.discovered.

With CloudEvents format on, an alert firing arrives as:

{
  "specversion": "1.0",
  "id": "7c1b8e02-90cf-45f2-8b4c-2f6a5d3e9b10",
  "source": "https://sluicio.example.com",
  "type": "com.sluicio.alert.fired",
  "time": "2026-07-24T12:34:56Z",
  "subject": "alert/orders-backlog",
  "data": {
    "state": "firing",
    "severity": "critical",
    "summary": "Orders backlog: queue.depth 12500 > 10000 over 5m",
    "rule": { "name": "Orders backlog", "signal": "metric" },
    "link": "https://sluicio.example.com/alerts?instance=8f2c…"
  }
}

With the default format, the same emission is the flat shape:

{
  "event": "com.sluicio.alert.fired",
  "id": "7c1b8e02-90cf-45f2-8b4c-2f6a5d3e9b10",
  "time": "2026-07-24T12:34:56Z",
  "subject": "alert/orders-backlog",
  "source": "https://sluicio.example.com",
  "data": {
    "state": "firing",
    "severity": "critical",
    "summary": "Orders backlog: queue.depth 12500 > 10000 over 5m",
    "rule": { "name": "Orders backlog", "signal": "metric" },
    "link": "https://sluicio.example.com/alerts?instance=8f2c…"
  }
}

Route on type (or event) in your consumer, and dedupe on id if you’ve wired more than one subscription at the same platform.