At a glance
Merges In Progress is the live count of background part merges ClickHouse is running right now, read from theMergemetric insystem.metrics. A few concurrent merges is healthy housekeeping: ClickHouse is steadily combining the small parts created by inserts into larger, more efficient ones. A sustained high count is the warning sign that ingest is outpacing merge throughput, which is the road to a parts backlog and, eventually, aToo Many Partshalt.
What it tracks
The card reports the value of theMerge metric from system.metrics, which is the number of background merge operations executing at the sample instant. Every INSERT into a MergeTree table writes a new data part; ClickHouse continually merges those parts in the background to keep part counts low and reads fast. The count rising and falling through the day is normal. The signal to watch for is a sustained high count: that means new parts are arriving faster than the merge scheduler can consolidate them, so the parts backlog grows. Left unchecked, the backlog drives up Active Parts (Top 10 Tables) and can trip the Too Many Parts cap that halts ingest on the affected table. The card has no fixed alert threshold (time_window is RT); read it alongside active-parts and ingest-rate cards to judge whether the merge load is keeping up. The typical cause of a runaway count is too-frequent small inserts; batching inserts (fewer, larger INSERTs) is the standard fix.
Reconciling against the source
Confirm the live count directly withSELECT value FROM system.metrics WHERE metric = 'Merge', and see the actual running merges (table, progress, elapsed) with SELECT table, elapsed, progress, rows_read, rows_written FROM system.merges. On ClickHouse Cloud the same system.merges and system.metrics reads apply per node.