OCI Notifications: Alerts, Topics, and Subscriptions

Every cloud estate needs a reliable way to tell a human that something happened. A disk filled up, a budget threshold tripped, a deployment failed at two in the morning. On Oracle Cloud Infrastructure, the service that carries that message from the platform to a person, or to a tool that wakes a person, is OCI Notifications. It is small, unglamorous, and close to free, yet it sits on the critical path of nearly every operational design we build. Configured well, the right people learn about the right problems at the right speed. Configured badly, the first sign of an outage is a customer phone call.

This article is the deep dive on Notifications within our series on application development and serverless on OCI. We will cover what the service is, how the subscription protocols differ, how topics plug into Monitoring, Events, and Service Connector Hub, what the limits and retry behavior mean for your designs, how to build a topic taxonomy that scales, and the mistakes we keep finding in tenancy reviews.

What OCI Notifications actually is

OCI Notifications is a managed publish and subscribe service, and the model has exactly two nouns. A topic is a named channel that publishers send messages to. A subscription attaches a delivery endpoint to a topic: an email address, an HTTPS URL, a PagerDuty integration, a Slack channel, a phone number for SMS, or an OCI Function. Publish a message to a topic and the service delivers a copy to every confirmed subscription. One publish, many deliveries, with the fan out handled entirely by the platform, no broker to size, and no cluster to patch.

The delivery model is push, and that distinction matters for choosing the right tool. With OCI Queue, consumers pull messages at their own pace, each message is processed by one consumer, and the queue holds a durable backlog while consumers are slow or offline. Notifications inverts all of that: it pushes every message to every subscriber immediately, keeps no readable backlog, and drops anything it cannot deliver within the retry window. Queue is for work that one worker must process. Notifications is for announcements that many parties should hear at once.

The service is also the messaging fabric of the platform itself. Monitoring alarms, Events rules, budget alerts, Cloud Guard problems, and DevOps pipeline notifications all publish to topics, so even if your code never calls the publish API directly, your tenancy is almost certainly using Notifications already.

Subscription protocols compared

Each subscription speaks one protocol, and the protocols differ in how they are confirmed and what they are good for. Here is the practical comparison.

Two of these deserve extra comment. The HTTPS endpoint protocol is the universal escape hatch: anything that can receive a webhook can subscribe, but you own the availability of that endpoint, and one that keeps returning errors will eventually cause messages to be dropped. The Functions protocol is the most powerful, because it turns a notification into code execution: a subscribed function can enrich an alarm with context, open a ticket, restart a resource, or republish a reformatted message to a second topic, which is how we build custom routing on OCI without any standing infrastructure.

How topics plug into the rest of OCI

Monitoring alarms

The single most important integration is with the Monitoring service, because alarm to topic to subscriber is the canonical alerting path on OCI. An alarm watches a metric, fires when its threshold condition holds, and publishes its state changes to one or more topics. Everything downstream, who gets paged, who gets emailed, which Slack channel lights up, is decided by the subscriptions on those topics rather than by the alarm itself. Alarms decide what is worth saying; topics and subscriptions decide who hears it and how. That is also why a poorly structured set of topics undermines even perfectly tuned alarms, a failure mode our OCI monitoring service spends a surprising amount of time untangling.

Events rules

The OCI Events service emits structured messages when resources change state: an object lands in a bucket, an instance terminates, a database backup completes. An Events rule can deliver matching events straight to a topic, which means any resource change in the tenancy can notify a human or a webhook with no code at all. We use this constantly for governance signals, telling a security channel when someone creates a public bucket, or telling a platform team when a new compartment appears.

Service Connector Hub

Service Connector Hub moves data between OCI services in managed pipelines, and Notifications can sit at the end of one. A connector can read from Logging, filter for specific entries, and publish matches to a topic, which gives you log driven alerting without running any aggregation software. But Notifications is a terminal hop for humans and webhooks, not a transport for high volume data; bulk log or telemetry movement should target Object Storage or Streaming instead.

Message format and size limits

A published message has a title and a body, and the body is capped at 64 KB. Messages from platform sources arrive as JSON: an alarm message carries the alarm name, severity, metric values, dimensions, and timestamps in a documented structure that downstream code can parse reliably. For human subscribers, email subscriptions can render alarm JSON into a readable format instead of dumping the raw payload into the inbox. Use it; raw JSON in an email is the fastest way to train people to ignore alerts.

The limits shape designs in two ways. First, 64 KB is plenty for an alert and useless for data transfer, so never stuff payloads through a topic; publish a reference, such as an Object Storage URI, and let the consumer fetch the data. Second, SMS messages are truncated aggressively, so a topic with SMS subscribers should carry short, scannable summaries, not paragraphs that will be cut off mid sentence.

Delivery retries and endpoint failure

Notifications retries failed deliveries automatically with increasing backoff, and the retry window is measured in hours, not days. The exact budget varies by protocol, but the operational meaning is the same everywhere: if the endpoint stays unreachable for the whole window, the message is dropped permanently, with no dead letter queue and no replay. A webhook receiver that is down over a weekend will simply miss everything published while it was out.

Design accordingly. Where loss is unacceptable, pair the topic with a durable record: have the same source write to a Queue or a log as well, or subscribe a function that persists every message before acting on it. Alarm on the failed delivery metrics the service emits per topic, because a silently failing subscription is indistinguishable from a quiet system until the day you needed the alert. And keep webhook receivers boring: acknowledge quickly, do heavy work asynchronously, and never let a slow downstream system burn through the retry budget.

Designing a topic taxonomy

The most consequential decision is not any single subscription; it is how many topics you create and what each one means. The antipattern we see most often is one giant topic, usually called something like alerts or ops, with every alarm in the tenancy publishing to it and a dozen subscribers receiving everything. It works for the first month. Then the volume grows, people filter the noise into folders, and the channel is dead as an alerting mechanism even though it is technically delivering every message.

The fix is a taxonomy with three axes. Split by environment, so a noisy test system can never desensitize anyone to production signals. Split by severity, so messages that should page someone travel on different topics from messages that can wait for the morning. Split by team where ownership is clear, so the database group hears about database problems instead of everyone hearing about everything. A name like prod sev1 database tells you exactly what belongs on it and who should subscribe. Topics cost nothing to create, so the constraint is clarity, not budget: every topic should have a one sentence answer to who needs this and how fast.

Subscription confirmation and lifecycle

A subscription delivers nothing until it is confirmed. Email, Slack, SMS, and HTTPS subscriptions start in a pending state and require the endpoint to confirm through the link the service sends; PagerDuty and Functions subscriptions confirm automatically. This is a sensible abuse prevention measure with a nasty operational consequence: a subscription that is never confirmed sits in pending forever, looks present in every console listing, and delivers absolutely nothing, while whoever created it walks away believing the alert path exists.

Lifecycle is the slower version of the same problem. People change teams, distribution lists get retired, webhook receivers get decommissioned, and the subscriptions pointing at them remain. We recommend a quarterly review of every production topic: verify each subscription is confirmed, points at a live endpoint, and has a current owner, and delete the rest. Keeping topic and subscription definitions in Terraform makes the review a diff instead of an archaeology project.

Operational alerting design that works

Put the pieces together and a sound alerting design on OCI looks like this. Severity one alarms, the ones that mean customers are affected right now, publish to a dedicated topic per environment whose only subscribers are PagerDuty and, as a backstop, an SMS subscription for the duty manager, so a page always means action. Medium severity alarms publish to team topics with Slack subscriptions, giving engineering channels ambient awareness without waking anyone. Low severity and informational messages, capacity trends, budget notices, certificate expiry warnings, go to email topics that owners scan daily as a digest rather than one by one.

The same structure extends beyond alarms. Build and deployment notifications from OCI DevOps publish to the team Slack topics, so a failed deployment appears in the same channel as the alarms it might cause, and Events rules feed governance topics watched by the security function. The result is a small set of topics, each with a clear meaning and a protocol matched to its urgency, and an on call rotation that can trust the loud channel is always worth waking up for.

What it costs

For most estates, Notifications is effectively free. Publishes are billed per million after a monthly free allowance, at a rate measured in fractions of a dollar, so an estate would need a torrent of messages before the line item became visible on an invoice. Email and SMS deliveries carry small pass through charges reflecting what carriers and mail infrastructure cost underneath, and SMS rates vary by destination country, so check them before paging international phone numbers. HTTPS, Slack, PagerDuty, and Functions deliveries add nothing beyond the publish itself. Cost should never drive a Notifications design decision; the whole service typically costs less per month than one minute of the outage it helps you catch.

Common mistakes

Three failures account for most of what we find in reviews. The first is alert fatigue from unfiltered topics: every alarm publishing to one shared topic, every engineer subscribed, and within months the channel is muted and the one message that mattered scrolls past unread. The taxonomy above is the cure, and it is far cheaper to build early than to retrofit. The second is unconfirmed subscriptions silently dropping everything: someone subscribes a distribution list, nobody clicks the confirmation link, and the alert path everyone believes exists has never delivered a single message. Always test publish after creating a subscription, and audit for pending state regularly. The third is secrets in message bodies: messages fan out to inboxes, chat channels, and third party services, all outside your IAM boundary, so a connection string or token published to a topic has effectively been broadcast. Publish identifiers and references, never credentials.

A seven step framework for your alerting taxonomy

This is the sequence we use when building or rebuilding an alerting layer on Notifications.

Bringing it together

OCI Notifications is one of those services where the engineering is trivial and the design is everything. The platform gives you reliable fan out, six delivery protocols, automatic retries, and a price close to zero; what it cannot give you is a sensible taxonomy, confirmed subscriptions, and a team that trusts its alert channels. Those come from deliberate design, and they pay for themselves the first time a severity one page reaches the right engineer in under a minute instead of dying in a muted channel. If your topics and on call wiring have grown organically and nobody is sure who hears what anymore, that is a small, fast piece of work to put right.