SCTE-35 monitoring is the practice of watching the ad-signalling markers in your live stream in real time — confirming that every cue-out and cue-in fires correctly, in the right place, with the right values — so a broken marker never quietly turns into a missed ad break. It matters because SCTE-35 failures are silent: the video keeps playing perfectly while the ad revenue disappears, and most teams don’t find out until the numbers come in short days later.
If you monetize live or linear video, the markers in your stream are the difference between an ad break that plays and one that doesn’t. This guide explains what SCTE-35 monitoring is, how markers fail without breaking the stream, what each decoded field actually tells you, and how validation turns ad-break integrity from a monthly surprise into something you can see as it happens. For the underlying standard itself, our guide to what SCTE-35 is covers the fundamentals; here we focus on making sure it actually works.
TL;DR
- SCTE-35 markers signal when ad breaks open and close. When one fails, the stream keeps playing but the ad break silently doesn’t happen — so the loss is invisible until the ad report arrives.
- Common causes are mundane: a misconfigured encoder, a passthrough that strips the cue, a mismatched event ID, or a wrong break duration.
- Real-time monitoring detects and decodes every splice event as it fires; validation confirms it’s correctly formed and paired; alerting tells you when an expected marker goes missing.
- Clean signalling is also the on-ramp to monetization — the same validated markers are what server-side ad insertion uses to stitch in ads.
What SCTE-35 Monitoring Actually Means
SCTE-35 is the standard set of markers embedded in your stream that tell every downstream device exactly when an ad break should start, how long it should run, and when to return to content. SCTE-35 messages ride inside the transport stream and, when your packager converts to HLS or DASH, become manifest tags that players and ad servers read. That chain — encoder to packager to player — is where things can go wrong.
Monitoring is the layer that watches this signalling as it happens. Rather than assuming your markers are firing, SCTE-35 monitoring reads the signalling on your source, detects each splice event the moment it occurs, decodes it so you can see the actual values, and confirms the markers are complete and correctly paired. It answers the one question every ad-supported operator eventually asks: are the markers actually being triggered from my input?
The Core Problem: Markers Fail Silently
Here is what makes SCTE-35 uniquely dangerous compared to other stream faults. A dropped video segment causes visible buffering. A failed audio track is obvious in seconds. But a failed SCTE-35 marker breaks nothing you can see. The picture keeps playing, the audio stays in sync, and the only thing missing is the ad break that was supposed to fire.
A single misconfigured encoder, a passthrough setting that strips the cue during transcoding, a mismatched event ID, or an incorrect break duration can each break ad insertion without breaking the stream. Because nothing on the surface signals a problem, most teams discover it the slow way: the monthly ad report comes in short, and by then every break in that window is already gone. You cannot make up an impression that never fired.
This is precisely why monitoring exists. Detection tells you what did happen on your stream; alerting tells you what didn’t. Catching a broken signalling chain the moment it breaks — rather than in next month’s reconciliation — is the entire value proposition.
How Markers Break: The Failure Points
SCTE-35 markers travel through several stages, and each hop is a place a marker can drift, duplicate, disappear, or land on the wrong boundary. Understanding the chain is what lets you localize a fault instead of guessing.
At the encoder
The marker’s journey through your pipeline begins at the encoder, which is responsible for carrying the SCTE-35 signalling into the compressed stream. If the encoder is misconfigured to strip or ignore the relevant data, markers never make it downstream at all. The video looks completely normal, which is exactly why this failure goes unnoticed without monitoring.
At the passthrough or transcode step
Any time the stream changes container, gets transcoded, or moves between systems, the SCTE-35 metadata has to be carried through intact. This is one of the most common places markers are lost — a transcode step that isn’t configured to preserve the signalling drops it silently. The video passes through fine; the cue does not.
At the packager
When your packager converts the stream to HLS or DASH, it has to translate each SCTE-35 message into the corresponding manifest tags so players and ad servers can act on them. If the packager mishandles this, you can end up with a break that opens but never closes, a duplicated marker, or a mismatch between the declared break duration and what the manifest actually signals — any of which confuses the ad-decisioning downstream.
In the timing
Even a marker that survives the whole chain can still fire at the wrong moment. A cue can leave the encoder on time and still land late for the viewer if something downstream adds delay, so the break opens over the wrong frame. This is why monitoring looks at the timing of each cue, not just its presence.
Where Markers Live: Transport Stream vs. Manifest
One reason SCTE-35 problems are easy to miss is that the marker exists in more than one place along the chain, and a fault in one representation doesn’t always show up in the other. In the compressed transport stream, the SCTE-35 message rides as its own signalling data alongside the audio and video. When your packager produces HLS or DASH, it has to translate that message into manifest-level tags — for HLS, the cue-out and cue-in markers that appear in the playlist — so that players and server-side ad insertion systems can act on them.
That translation step is a failure point of its own. A marker can be perfectly intact in the transport stream and then get dropped, duplicated, or mistranslated when it becomes a manifest tag — or the reverse, where a playlist marker is present but doesn’t correspond to a clean cue underneath. A break can also be signalled correctly in one ABR rendition and missing in another, so one clean variant doesn’t prove the whole ladder is healthy. This is why thorough monitoring looks at the signalling as it actually reaches the player, not just at the moment it leaves the encoder — the marker that matters is the one the ad system actually sees.
What Each Decoded Marker Tells You
A green light that says “a marker arrived” is not enough. To trust your signalling you need to see the actual decoded contents of each splice message — because the difference between a working break and a broken one often lives in a single field. Effective SCTE-35 monitoring surfaces the complete decoded splice information for every event, including the raw payload for byte-level verification. These are the fields that matter and what each one tells you:
- Command / Splice Insert — the SCTE-35 command type carried in the marker. It confirms a valid splice was actually signalled, not just that some data appeared.
- Table ID (0xFC) — identifies the packet as a genuine SCTE-35 splice information table, distinguishing real signalling from noise.
- Splice Event ID — the unique identifier that ties a cue-out to its matching cue-in. If the opening and closing markers don’t share an ID, the break won’t pair correctly.
- Out of Network indicator — flags the start (1) and end (0) of an ad avail: the exact moment your break opens and closes. This is the heartbeat of the whole mechanism.
- Break Duration — the declared length of the ad avail in seconds. If this disagrees with what your ad system expects, breaks run long, cut short, or return to content over the wrong frame.
- PTS / PCR timestamps — the presentation and clock timestamps that pin the cue to a precise frame position. These are what you check when a marker is present but mistimed.
- Break Auto Return — whether the break is set to return to content automatically. A wrong auto-return flag is a classic cause of a program resuming early.
- Segmentation Type / Event ID — segmentation descriptor data used by more advanced ad-decisioning workflows.
- PID / Program — the elementary stream and program the marker belongs to, confirming it’s riding where it should.
- Raw Payload — the full base64 SCTE-35 payload, available for byte-level verification when you need to prove exactly what was signalled.
This is the difference between knowing that a marker came through and knowing that the right marker came through — correctly formed, correctly paired, and at the right time.
What Effective SCTE-35 Monitoring Does
Pulling the failure points and the decoded fields together, a capable SCTE-35 monitoring and validation setup should do four things, in real time, on your actual input:
Detect every cue as it fires
The baseline is real-time detection: every cue-out and cue-in identified the instant it happens on your input, with no waiting and no guessing. This is what turns an invisible signalling chain into something you can watch live.
Decode every field
Detection alone isn’t assurance. Full decoding of each marker — the command, event ID, break duration, timing, and the rest of the fields above — is what lets you verify a marker is correctly formed rather than merely present.
Validate pairing and duration
Good monitoring confirms that every break which opens also closes, with matching event IDs, and validates declared break durations against what the stream actually carries. Unpaired cues and duration mismatches are among the most common causes of black frames and early returns to content.
Alert on missing markers
The piece that saves revenue is alerting. When an expected marker fails to arrive on your input, you get notified — so you catch a broken encoder or passthrough the moment it breaks, and move from reactive troubleshooting to real-time assurance instead of discovering the gap in a later ad report.
Do it continuously, not once
A one-time check before launch proves the pipeline worked at that moment; it says nothing about the break that fires at 2 a.m. three weeks later after an encoder restart. Marker health drifts — a configuration change, a software update, or a restart anywhere in the chain can start dropping cues that were fine the day before. That’s why monitoring is a continuous posture rather than a pre-flight test: the value is in catching the regression whenever it happens, on whichever channel it happens to, without a human watching every feed. For an operator running many channels, that around-the-clock coverage is the whole point — no team can manually eyeball every break on every rendition of every channel.
Logs, Reconciliation, and Stream Health
Real-time detection handles the present; a retained history handles everything after. A complete, timestamped log of every marker event means the record is always there when you need it — for auditing your signalling, reconciling the breaks you signalled against the ads actually delivered, or handing a clean history to an ad partner during a dispute. Being able to export that history (for example, to CSV) is what makes offline analysis and reporting practical.
It also helps to see stream health in the same view. When a break looks wrong, tracking the live stream stats alongside the marker data — bitrate, resolution, codec, frame rate, and audio parameters — lets you tell instantly whether you’re looking at a signalling problem or an underlying stream problem. Two signals on one screen removes a whole layer of guesswork.
Who Needs SCTE-35 Monitoring
Anyone whose business depends on SCTE-35 for ad placement has a direct stake in whether those markers fire. In practice that means:
- Broadcasters inserting ad breaks into linear and live feeds, where a dropped cue is lost airtime.
- OTT and streaming platforms running server-side ad insertion, where marker integrity directly drives fill and revenue.
- FAST channel operators monetizing 24/7 linear channels, where breaks fire around the clock and no one is watching every one manually.
- Content and playout teams who need to prove their signalling is correct — to an ad partner, an advertiser, or their own management.
From Clean Signalling to Reliable Ad Breaks
Validating your markers isn’t the end of the workflow — it’s the on-ramp to monetizing them. Once you know your cues are firing cleanly, those same markers are exactly what an ad pipeline uses to place breaks. 5centsCDN turns validated signalling into revenue: Ad Insertion stitches ads into your live and VOD streams using the very markers you’re validating, Ad Manager handles campaigns and ad decisioning, and the FAST Channel Builder launches monetized 24/7 linear channels end to end. If SCTE-35 signalling and ad-supported streaming are on your roadmap — or you rely on a live transcoding pipeline that has to carry markers through intact — talk to our team and we’ll help you get your signalling clean and your breaks reliable.
Frequently Asked Questions
What is SCTE-35 monitoring?
SCTE-35 monitoring is the real-time practice of watching the ad-signalling markers in your stream to confirm they fire correctly. It detects each cue-out and cue-in as it happens, decodes the marker so you can see its actual values, validates that breaks pair correctly and durations match, and alerts you when an expected marker goes missing — so a broken signalling chain is caught immediately instead of showing up as lost revenue in a later ad report.
Why do SCTE-35 markers fail without breaking the stream?
Because SCTE-35 signalling is separate from the audio and video. A misconfigured encoder, a passthrough or transcode step that strips the cue, a mismatched event ID, or a wrong break duration can each stop an ad break from firing while the picture and sound keep playing perfectly. There’s no visible symptom, which is why the failure is usually discovered only when ad numbers come in short.
What’s the difference between SCTE-35 detection and validation?
Detection confirms that a marker arrived on your input. Validation goes further: it decodes the marker and checks that it’s correctly formed — that a cue-out has a matching cue-in with the same event ID, that the declared break duration is right, and that flags like auto-return are set correctly. Detection tells you something fired; validation tells you the right thing fired, correctly.
How do I know if my ad markers are actually being triggered?
The reliable way is real-time monitoring on your source stream. Rather than assuming the markers are firing, a monitoring tool reads the SCTE-35 signalling on your input and shows each splice event as it happens, with the decoded fields. If an expected marker doesn’t arrive, alerting flags it. That live picture is the only way to know for certain, short of waiting for the ad report.
How long should I keep SCTE-35 logs?
Long enough to cover the window in which an advertiser could raise a discrepancy — which in practice means keeping a complete, timestamped history you can pull on demand. A retained, exportable log of every marker event lets you reconcile signalled breaks against delivered ads and hand a clean record to an ad partner if a dispute arises.
Is SCTE-35 monitoring only for large broadcasters?
No. Any operator that monetizes with ad breaks has the same exposure — arguably more so for lean OTT and FAST teams who can’t watch every channel manually. If your revenue depends on breaks firing, monitoring protects it regardless of scale.
Conclusion
SCTE-35 failures are quiet, and that quietness is exactly what makes them expensive. A marker that never fires, a break that opens but never closes, a duration that doesn’t match — none of it disturbs the picture, so none of it announces itself. SCTE-35 monitoring replaces that blind spot with real-time certainty: every cue detected and decoded as it fires, every break validated, and an alert the moment one goes missing. Get the signalling right and your ad breaks stop being a monthly surprise — and the same clean markers become the foundation your monetization is built on.
