An Eventstream carrying humidity and light readings from gallery conservation sensors feeds a table in an Eventhouse. After a branch upgrades its sensor firmware, the field names in the incoming JSON payload change slightly, and the Eventhouse's ingested row count drops sharply overnight even though the sensors are still transmitting. Where should the engineer look to confirm the cause?

An Eventhouse in Real-Time Intelligence tracks ingestion outcomes at the record level, and when incoming data does not map cleanly onto a target table's expected schema, those records are rejected with a recorded reason rather than silently dropped, which makes the ingestion failure details the direct place to confirm a schema or mapping mismatch such as a renamed sensor field. A dropped row count with sensors still transmitting is a classic signature of exactly this kind of mapping break, since the data is arriving but no longer landing. The capacity metrics app reports compute throttling and consumption across the tenant, which would not explain why ingestion is selectively rejecting rows for one specific stream while the underlying source keeps sending. The Eventstream's source authentication settings govern whether the stream can connect to the sensor feed at all; a rename of an internal JSON field would not break authentication, since the connection itself remains valid. Git integration commit history tracks version control of Fabric item definitions and has no visibility into runtime data shape drift coming from a physical sensor's firmware. As an operational check, compare the field names in a recent raw sample from the upgraded firmware against the Eventhouse table's column mapping to confirm exactly which field renamed.