At a glance
Inserts per Second (live) is the live row-ingest rate into ClickHouse: how many rows are landing per second right now, measured as the delta of the InsertedRows event between two poll samples. ClickHouse is built for high-throughput ingest, so this is the pulse of your write pipeline. For a DBA, it answers “is data still flowing, and how fast?” A healthy stream is steady or follows a predictable daily shape; a sudden drop to zero while you expect traffic means the pipeline upstream has stalled, and a sudden spike often precedes a parts/merge backlog if the inserts are small and frequent.
Calculation
ClickHouse exposes cumulative profile counters insystem.events. InsertedRows is monotonically increasing since server start: the total rows ever inserted. A single reading is meaningless as a rate, so the card differences two consecutive samples:
INSERT ... VALUES of 50,000 rows in one batch adds 50,000 to the counter, the same as 50,000 single-row inserts, but the two have wildly different cost profiles on the merge side (the batched insert creates one part; the 50,000 single inserts create up to 50,000 tiny parts and a merge storm). The companion Inserts per Second reading is therefore best read alongside the parts cards.
Worked example
A clickstream platform ingests page-view events into ClickHouse via a Kafka consumer. The live insert rate normally tracks site traffic: roughly 12,000 rows/sec at the daytime peak, dropping to about 1,500 rows/sec overnight. On 03 Jun 26 at 13:15 the on-call SRE notices the card reading 0 rows/sec during what should be the lunchtime peak.- Is ClickHouse accepting writes? A test
INSERTsucceeds, so the server is healthy. The problem is upstream. - Is the Kafka consumer alive? The consumer group’s lag is climbing fast, confirming the consumer has stopped committing. The events are still arriving at Kafka; they are just not being drained into ClickHouse.
- Zero is the loudest reading on this card. A steady or shaped non-zero rate is healthy. Zero (during expected traffic) almost always means the problem is upstream of ClickHouse, not in it. Test a manual insert first to split server from pipeline.
- Rows/sec is not statements/sec. The same throughput can come from a few big batches (cheap, one part) or many tiny inserts (expensive, a merge storm). When the rate is high, glance at the parts cards to see which pattern you have.
- The dangerous moment is the recovery, not the stall. When a stalled pipeline restarts, the backlog drains in a burst. If that burst arrives as many small inserts, the parts backlog can spike and trigger a Too Many Parts error. Watch the parts cards while ingest catches up.
Sibling cards
Reconciling against the source
Confirm the cumulative counter the rate is derived from:system.metric_log must be enabled; it is on by default in most builds.) For a near-real-time view, system.asynchronous_metrics and the SELECT * FROM system.events WHERE event LIKE '%Insert%' family also help.
On ClickHouse Cloud, the service Monitoring tab plots inserted rows over time; reconcile its insert-rate chart against the system.events delta above.
Why our number may legitimately differ:
Known limitations / FAQs
The rate just jumped to a huge number for one poll. Is that real? Check whether the server restarted.InsertedRows is cumulative since start and resets to zero on restart; the first delta after a restart can look like a spike or a negative and is suppressed by the engine. If there was no restart, a genuine one-poll spike usually means a large batch insert (a backfill or a bulk load) landed in that interval.
The rate is zero but I am sure data is being sent. What is wrong?
Split the problem in two. First, confirm ClickHouse accepts writes with a manual test insert; if it succeeds, the server is fine and the issue is upstream (a stalled Kafka consumer, a paused ETL job, a network break between producer and ClickHouse). If the manual insert fails, the server is rejecting writes, check disk usage and the parts cards for a Too Many Parts halt. Zero almost always points upstream.
Does this count rows or insert statements?
Rows. A single batch of 100,000 rows and 100,000 single-row inserts both add 100,000 to InsertedRows, so they show the same rate, but they have very different merge cost. When the rate is high, glance at Active Parts (Top 10 Tables) to tell a cheap batched pattern from an expensive small-insert pattern.
Why is there no alert threshold on this card?
Because the healthy value depends entirely on your workload: 50 rows/sec is fine for a reference dataset and alarming for a clickstream. A fixed threshold would be wrong for everyone. The meaningful alert is contextual: ingest stalling while business activity continues, which the cross-platform ClickHouse Event Ingest vs Ecom Orders card owns.
On a multi-node cluster, is this the whole cluster or one node?
By default it is the connected node, because system.events is per-node. Inserts that route to other nodes are not in the connected node’s counter. For a cluster-wide rate, the engine can be configured to sum InsertedRows across clusterAllReplicas.
The rate looks smoother than my ingest actually is. Why?
The card is a delta over the poll interval, so any burst shorter than the interval is averaged out. If you need sub-poll resolution, query system.metric_log directly, which records ProfileEvent_InsertedRows at a finer cadence.
Insert rate is healthy but my data looks stale in queries. How?
A high insert rate means rows are landing on disk as parts, but readers may not see them until parts are visible and, on followers, until replication catches up. If inserts are healthy on the leader but reads on a replica are stale, the problem is replication, not ingest, check Replication Lag (absolute_delay).