What did this row say a minute ago?

A corridor went red for about fifteen seconds and is now green again. Everybody saw it out of the corner of their eye, nobody was looking directly at it, and the only record that it happened is four people in a room disagreeing about which merchant it was.

Drag the scrubber under the grid above backwards. The grid winds back through the changes it has recorded, and the cells that moved between where you are and where you were are marked. The corridor that went red is the one with the marks on it.

The change log, not the undo history

Almost every grid that offers anything like this offers undo, and undo answers a different question. Undo is a record of what you did: the edits you made, the columns you moved, the filter you applied. It is the right tool when you have broken something and want it back.

On a screen that is being fed from somewhere else, you did not do anything. The data did. Undo has no entry for “the approval rate on this corridor fell”, so winding back an undo stack on a live grid takes you through your own filter changes while the numbers carry on being whatever they are now. It is the wrong history.

What the scrubber reads is the change log: every value the grid was told to write, with the row it belonged to and when it arrived. Seeking backwards replays those writes in reverse, so the grid shows the values as they stood at that moment rather than as they stand now. Go forward again and it catches back up to live.

That is also why the recording has to be switched on before it is useful. What a cell used to say is not recoverable after the fact from a cell that has already been overwritten, so the grid starts keeping the log when the timeline is attached and keeps a bounded window of it. The demo above holds six hundred changes, which on that feed is a couple of minutes. While it is recording, the line under the grid tells you how many changes are held and how many seconds of history that reaches; once you start dragging it tells you how many changes back you are standing.

What people actually do with two minutes of history

The obvious use is the one above: something flickered and you want to see it again without waiting for it to happen twice.

The more common one is quieter. Somebody is on a call and says “it was fine ten seconds ago”, and instead of arguing they wind back ten seconds and everyone looks at the same screen. An incident call is often two people describing different moments in time to each other with equal confidence, and a shared scrubber ends that conversation faster than any amount of logging.

The third is checking your own eyes. A number moved and you are not sure whether it moved a lot or you misread it. Step back one change. The mark tells you which cells were touched and the value tells you what they were.

The timeline is a bounded window in the browser, sized to the last couple of minutes. Proving what a value was at 14:32 last Thursday is a question for your database; this is for the fifteen seconds you missed.

Why it is unusual

The reason most grids do not have this is not that replay is hard. It is that the grid has no idea a value changed, because it was handed a new array of rows and re-rendered from scratch. A grid that cannot tell you which cells moved between two renders certainly cannot tell you what they said a minute ago.

This one identifies rows by key and applies changes as changes, which is what makes the highlight on an updated cell possible in the first place. The timeline is that same information kept for two minutes instead of half a second. Your users get it because it ships in the grid, and nobody on your team writes a ring buffer.

Watch it recording on the live demo or read how the change log is bounded.