Understanding Salesforce Platform Event Delivery Limits

Published 28/02/2025

A critical alert from Salesforce Signature Success landed like the kind of message no admin wants to see on a Monday morning: the production org had hit a hard platform limit. Specifically, the platform event delivery allocation had been completely consumed. Once that allocation is exhausted, Salesforce can no longer guarantee that events will be delivered on time—or at all. In practical terms, this meant the event bus was effectively jammed.

At first glance this seemed odd: most of the time, platform events “just work.” So what happened, and why did the alert appear?

What Actually Happened

Salesforce’s notification pointed to one event channel in particular — /event/LogEntryEvent__e, the backbone of a logging solution. But what stood out wasn’t just the channel itself. The alert highlighted that a single user was responsible for consuming the vast majority of the platform event delivery allocation.

The logging solution was still creating Log records without issue and seemingly working normally, but the delivery limit had hit zero. That raised the obvious question: how can event processing continue if deliveries are supposedly exhausted?

How Platform Event Delivery Limits Work

Salesforce uses two main sets of limits for platform events:

Publishing limit: How many events the org can create or publish in 24 hours.
Delivery allocation: How many event notifications Salesforce can deliver to subscribers in 24 hours.

The delivery side is what trips people up. Deliveries are only counted for API-based subscribers, such as:

EmpApi and CometD streaming clients
Pub/Sub API consumers
Event relays or external integrations

Internal consumers like Apex triggers, Flows, or Process Builder are considered non‑API subscribers — their deliveries don’t count toward that cap.

That explains our earlier confusion: even though the delivery quota was gone, the Apex trigger that stored the log records could still run fine because Apex-based processing doesn’t use the delivery pool.

You can confirm this behavior in the official Platform Events Developer Guide.

The Real Cause

Eventually the investigation landed on one open browser tab. An admin had left a page of the logging solution open overnight; a page that displayed live log event data using a Lightning component subscribed to the event through the EmpApi.

That subscription stayed active for hours and kept receiving event data continuously. Every one of those messages counted as an API delivery, and over time they added up until the org’s daily limit was gone.

In other words, nothing malfunctioned, the system was simply doing exactly what it was asked to do, just someone made a mistake.

What Was Done Next

To make sure the same issue didn’t surface again, the team used the logging solutions existing Custom Metadata Type switch that controls whether the real‑time event stream is active. This feature had always been part of the logging solution, but in day‑to‑day operations it was easy to leave the stream enabled even when no one needed to watch events in real time. By turning the switch off, the team ensured that no one would accidentally open long‑running EmpApi subscriptions that quietly consume delivery allocations.

The logging pipeline itself kept functioning exactly as designed — Apex‑driven event handling continued uninterrupted — but the real‑time viewer was now explicitly disabled until someone intentionally re‑enabled it. This small configuration change removed the risk of background listeners burning through the delivery quota again.

A pattern like this is especially valuable in monitoring or diagnostic features that are only needed occasionally. A simple configuration flag gives teams a safe default (“off”), a clear operational choice (“turn it on when required”), and a fast rollback path if usage spikes unexpectedly.

Key Takeaways

Know your subscribers. Apex, Flows, and Process Builder don’t count against platform event delivery limits. The EmpApi and Pub/Sub clients do.
Monitor platform event usage. Watch delivery statistics in Setup or Event Monitoring to spot an issue before Salesforce does.
Throttle or timeout embedded subscriptions. Dashboards and monitoring tools that use EmpApi should disconnect when not in use.
Share the quota wisely. Delivery allocations are shared org-wide, so one chatty subscriber can impact everyone else.
Use configuration switches. Features controlled by custom metadata or settings make it easy to adjust behavior without a deployment.

Platform events are a powerful way to connect processes and systems, but like any shared resource, they need a little oversight. Keeping an eye on usage and knowing who’s consuming what ensures your event-driven architecture stays reliable — and avoids those unexpected delivery alerts.