Answer
Journal-based replication depends on a chain of moving parts: journal receiver management on the source, transmission to the target, and an apply process that has to keep pace with production activity. Any one link can degrade quietly. A journal receiver that fills faster than it can be offloaded, a communications line that drops packets during a batch window, or an apply job that silently skips a record because of a data type mismatch will all leave a dashboard showing green while the secondary copy quietly diverges. Buyers should ask vendors to demonstrate, not just describe, how the product detects and reports each of these failure modes separately, because a single aggregate status indicator hides more than it reveals.
The exception queue deserves particular scrutiny. Every mature replication product accumulates objects it could not apply automatically, whether from record locks, structural changes, or objects excluded by filter rules, and parks them for manual review. How that queue is surfaced matters as much as whether it exists. Ask how many exceptions accumulate in a typical week, who gets notified, and how long unresolved items usually sit before someone acts. A queue that grows unnoticed for months is functionally the same as having no monitoring at all.
Finally, ask how lag and exception reporting tie back to the actual recovery point objective. A five-second lag figure means little without knowing whether it reflects the last successfully applied transaction or simply the last transmission received at the target.