A conversion counter can fall while a pipeline still accepts events and returns successful responses. Before using the counter to make a decision, check whether accepted events are reaching the dataset that feeds it. That takes two different clocks. Event time tells you when the underlying action happened. Processing time tells you when each system handled it. With both clocks and a stable event identifier, an on-call engineer can find the handoff where work started to wait.
Measure freshness at the durable output
Pick an accepted event type and identify the exact table or materialized view the report reads. Keep the event timestamp and, where available, the broker acceptance, consumer processing and durable write timestamps. Use a common time standard and check clock skew before interpreting small differences. For the on-call view, choose a freshness objective that expresses how quickly accepted events should reach that output. Measure it on the result readers actually use. The Google SRE Workbook chapter on data processing pipelines describes ways to define freshness separately from correctness.
Track progress by partition or another bounded source group. A recent event in a healthy partition can make the output look fresh while older work waits elsewhere. Where the runner exposes an event-time watermark, compare its movement across the affected stages and check how idle inputs and late arrivals are handled. Pair it with the age of the oldest pending work you can observe. Measure that age from when the work entered the queue. An event that happened long ago but arrived just now has spent little time in the queue.
Find the handoff where work starts to wait
Put broker backlog, the consumer's successful processing rate and durable output writes on the same timeline. Look at queue age alongside depth. If both rise while acceptance continues and output slows, you have evidence that downstream processing has fallen behind. If processing remains steady but successful writes drop, inspect the sink for throttling, timeouts or a change to write errors. Compare the same partition and interval before deciding where to intervene. An aggregate rate across unrelated partitions can send the investigation to the wrong service.
Collector self-monitoring can tell you whether the observability path is falling behind too. Compare the Collector's exporter queue occupancy, successful sends and enqueue failures using the OpenTelemetry internal telemetry reference. If telemetry is dropping, corroborate the suspected application backlog with the broker or sink directly. Those Collector metrics describe the delivery of telemetry. Business event acceptance and durable output need their own evidence.
Trace one accepted event to the report input
Use an approved test event or a permitted existing record with a stable identifier. Find its broker receipt, then the matching consumer record and durable sink row. Check whether the consumer acknowledges work before or after the write commits. If it acknowledges early, a falling broker backlog gives you no assurance that the matching rows reached storage. If the sink row is present, verify whether the report input includes that event type and timestamp under its current rules.
This is where the reporting team needs to define what counts as a conversion. For example, a purchase can be accepted by the pipeline before the report's attribution cohort has matured, or the report may count only confirmed orders. Our FroggyAds conversion discrepancy guide documents how we separate reporting dates, cohort maturity and accepted outcomes when reconciling two reports. Use those distinctions to check whether the report should include the traced event once it is available. Use the pipeline evidence to establish when it became available.
Give the incident agent a bounded decision
Have the agent read the freshness objective, the affected partition, the oldest pending age and the last durable output it can verify. Keep that check read-only. A deterministic rule can flag a likely processing backlog when accepted work continues, pending age rises and the output falls behind its objective. The agent can summarize the ordering and identify the next read that would distinguish a slow consumer from a slow sink. It should flag unavailable or stale metrics explicitly and leave a change to concurrency, retry policy or report filters to the service owner.
During recovery, watch pending age fall and confirm that durable writes resume for the same partition. Then revisit one event from the affected interval. A fresh event arriving after recovery shows the current path is working. The earlier event tells you whether the backlog cleared in a way the report can actually use. Keep that distinction in the incident record before lifting any hold on decisions that depend on the affected data.