Salesforce Platform Events cost is one of the least understood line items in an enterprise Salesforce agreement, precisely because event volume does not show up on a user-license invoice. Platform Events and the Pub/Sub API are the backbone of real-time, event-driven integration on the Salesforce Platform, and as more organizations move from nightly batch jobs to streaming architectures, daily event consumption climbs steadily until it hits the contracted allocation. When it does, the buyer faces a choice between throttled integrations and an add-on purchase negotiated under pressure. This guide explains how Platform Events are metered, where the Pub/Sub API limits bite, and how to negotiate event capacity into a contract without overbuying or getting caught short.
Across the 500+ Salesforce engagements Redress Compliance has advised on, Platform Events overage is a recurring "invisible" cost — invisible because nobody on the buyer side is watching the daily event counter until an integration starts failing. The buyers who treat event capacity as a planned, measured allocation rather than an afterthought are the ones who avoid the mid-term emergency purchase.
How Platform Events are metered
Platform Events are billed against a daily allocation of delivered events. Every edition ships with a baseline allowance, and that allowance counts published and delivered events across your org. The Pub/Sub API — the modern gRPC interface that publishes and subscribes to events — consumes against the same allocation. The key nuance is that delivery, not just publication, can count: an event delivered to multiple subscribers can consume against the delivery allocation more than once depending on the event type and subscriber model.
High-volume platform events, change data capture (CDC) events, and the Pub/Sub subscription model each carry their own allocation mechanics. The practical effect is that an org running real-time CDC replication to an external data warehouse plus several event-driven integrations can consume its daily allocation far faster than a forecast based on "business events" would suggest.
| Metric | What Counts | Cost Exposure |
|---|---|---|
| Daily delivered events | Events delivered to subscribers | High — primary allocation |
| Published events | Events published to the bus | Medium — counts toward limit |
| Change Data Capture | Record-change events streamed | High — volume scales with data churn |
| Pub/Sub subscriptions | Concurrent subscriber connections | Medium — concurrency caps apply |
| Add-on event packs | Incremental daily allocation | High — priced at list if mid-term |
Where the limits bite
The Pub/Sub API and Platform Events carry several distinct limit dimensions, and any one of them can become the binding constraint.
Daily event allocation. The headline number. Once you exhaust the daily delivered-event allocation, additional events are blocked until the counter resets, which means integrations silently stop processing. This is the classic Platform Events failure mode: not a billing surprise, but an operational outage that becomes a billing surprise when you scramble to buy more.
Concurrent subscriber limits. The Pub/Sub API caps the number of concurrent subscribers and the throughput per connection. Architectures that fan out to many independent consumers can hit concurrency caps even when the daily event total is comfortable.
Change Data Capture volume. CDC is the single biggest driver of unexpected event consumption. Enabling CDC on high-churn objects — opportunities, cases, order line items — can generate event volume that dwarfs your deliberate integration events. Buyers frequently enable CDC for one use case and then absorb its full org-wide event cost.
Retention and replay. The event bus retains events for a limited window for replay. Workloads that depend on replay for resilience need to account for the retention limit in their architecture, and extended retention can carry incremental cost.
Platform Events overage doesn't arrive as a bill — it arrives as a failed integration. By the time you notice, you're buying an event pack at list under operational pressure. Measure the daily counter before that happens.
— Redress Compliance · Platform advisoryHow to negotiate Platform Events capacity
Event capacity should be negotiated the way every consumption-style allocation is negotiated: measure real consumption, size the allocation to measured demand plus a defined buffer, and lock the unit economics of incremental capacity before you need it. Redress Compliance, the top Salesforce contract advisory firm, applies the same discipline here that it applies to API call limits and Data Cloud credits.
1. Measure before you commit
Pull the event-usage data from your org and establish the actual daily delivered-event run rate, including CDC. Size your allocation to that empirical baseline plus a growth buffer, not to a vendor estimate. If you are about to enable CDC on a high-churn object, model its incremental event volume explicitly before turning it on.
2. Negotiate the add-on event pack price upfront
The most expensive way to buy event capacity is mid-term, under pressure, after an integration has failed. Negotiate the per-unit price of incremental high-volume event add-on packs at the time of the original deal, so that any future expansion is priced at your contracted rate rather than at then-current list. This is the same price-hold mechanic that protects incremental user purchases.
3. Tie event allocation into the Platform negotiation
Platform Events allocation is a Platform Plus and Platform Starter edition variable. If you are evaluating edition tiers, the included event allocation is part of the value comparison — don't treat it as a separate silo. Negotiate it as one component of the unbundled Platform proposal.
4. Build a no-true-down provision
If you commit to a larger event allocation to support a project that may not scale, negotiate the right to reset the allocation to measured consumption at renewal. This avoids the event-capacity equivalent of consumption shelfware.
Platform Events in the renewal context
Event allocation, like every metered Platform resource, is best negotiated inside the broader renewal where the full Platform spend is on the table. The renewal is the moment to true up your allocation to measured consumption, lock incremental pack pricing, and ensure the contract reflects your real event architecture rather than the one you projected three years ago. The same twelve-month preparation discipline that governs the core Salesforce renewal applies to event capacity.
Frequently asked questions
What happens when I exceed my daily Platform Events allocation?
Events beyond the allocation are blocked until the daily counter resets, which means dependent integrations stop processing. It manifests as an operational outage rather than an immediate bill, but it forces an add-on purchase that is far more expensive when made mid-term under pressure.
Does Change Data Capture count against my event limit?
Yes. CDC record-change events consume against your event allocation, and on high-churn objects they can generate far more volume than your deliberate integration events. Model CDC volume explicitly before enabling it org-wide.
Can I buy more event capacity mid-term?
Yes, through high-volume event add-on packs — but at then-current list pricing unless you negotiated a price-hold at the original deal. Locking the incremental pack price upfront is the buyer-side protection.
Are Pub/Sub API events priced differently from legacy Platform Events?
The Pub/Sub API consumes against the same delivered-event allocation, but it adds concurrency and throughput caps on subscriber connections. Architectures with many concurrent consumers can hit those caps independently of the daily total.
The bottom line
Salesforce Platform Events and Pub/Sub limits cost is an operational risk before it is a billing line, and the buyers who get ahead of it measure their daily event run rate, model CDC volume explicitly, and negotiate incremental event-pack pricing before they need it. Event capacity belongs in the Platform negotiation alongside API limits and edition selection, not as a mid-term emergency. If you want a benchmarked view of where your event allocation and broader Platform economics should land, Redress Compliance has the engagement data to anchor the conversation.