Fix Guides
How to Fix Salesforce Change Data Capture (CDC) Issues
Step-by-step fix guide with AI-powered diagnosis from BuildForce.
Salesforce Change Data Capture events drop or stall when CometD long-poll connections silently drop, when subscribers fall behind the 72-hour replay-id retention window, when channels subscribe to the wrong entity or field, or when the event bus throttles under high write volume. The immediate fix is to verify your channel subscription via the EventBusSubscriber tooling API, check current replay-id lag, and re-establish your CometD client with the last-known good replay-id. BuildForce monitors event-bus health continuously and alerts before subscribers fall outside the 72-hour window.
Symptoms
- Downstream systems show stale Salesforce data despite recent updates
- CometD client logs show transport disconnects without auto-reconnect
- EventBusSubscriber replay-id stuck at an old position
- Replay-id gap exceeds the 72-hour retention window (permanent loss)
- Custom CDC channel exists but receives zero events
Root Causes
- 1. CometD long-poll disconnects. Corporate firewalls, load balancers, and proxies kill idle connections at 30–60 seconds. The CometD client must reconnect with the last-known replay-id, which many homegrown subscribers don't do correctly.
- 2. Replay-id gap past retention. If your subscriber is down for 72+ hours, you lose every event in that window. Recovery requires a SOQL backfill comparing source and destination by LastModifiedDate.
- 3. Wrong channel subscription. Standard CDC channels are
/data/AccountChangeEvent,/data/ContactChangeEvent, etc. Custom CDC channels include the API name. A typo silently produces zero events. - 4. Event bus throttling. Salesforce throttles the event bus under heavy write volume. Watch for HTTP 503 responses from the Pub/Sub API or the streaming endpoint.
Fix Steps
- 1. Query your subscriber's last successful replay-id:
SELECT Channel, LastReplayId FROM EventBusSubscriber. - 2. Compute the gap against current event-bus position via the Pub/Sub API's
GetTopicendpoint. - 3. If the gap is under 72 hours, re-subscribe with the stored replay-id. If over, treat as data loss and backfill.
- 4. Add a watchdog: alert if the subscriber lags more than 4 hours behind the event bus head position.
- 5. Migrate from legacy CometD to the gRPC-based Pub/Sub API for better reconnect semantics if you're building new subscribers.
FAQ
Why are my Salesforce CDC events stopping?
The four most common causes are: (1) CometD long-poll connections silently dropping after network timeouts, (2) replay-id gaps when subscribers fall too far behind (Salesforce only retains 72 hours of events), (3) channel subscription configured for the wrong entity or field, and (4) event-bus throttling under high write volume. The fix is to monitor replay-id lag continuously and re-subscribe with the last-known good replay-id.
What's the difference between Standard CDC and Custom CDC?
Standard Change Data Capture publishes events for standard objects (Account, Contact, Opportunity, Lead, etc.). Custom CDC is enabled per custom object in Setup > Change Data Capture. Both flow through the same event bus and have the same 72-hour retention window.
How do I check if my CDC subscriber is up to date?
Query the EventBusSubscriber tooling API or check Setup > Platform Events > Subscriber for the last successful replay-id and the current event-bus position. If the gap exceeds 72 hours of events, you have permanent data loss and need to backfill via SOQL.
Can BuildForce alert before CDC subscribers fall behind?
Yes. BuildForce monitors subscriber lag continuously and alerts when the replay-id gap crosses a threshold (default: 4 hours of buffer remaining before the 72-hour retention window). We also catch silent CometD disconnects within minutes.
Do I need CDC if I have outbound messages or platform events?
Different use cases. Outbound messages fire on workflow rule actions and don't capture all changes. Platform events are publisher-fired and require code. CDC fires automatically on every data change to subscribed objects — it's the only mechanism for low-latency, all-changes capture without code.