Who Did This, and When?

The story

At 3:14 a.m., 5,000 tickets to a sold-out festival were refunded. All of them. In about ninety seconds. By the time the on-call alert fired and Mara was awake and horrified, the damage was done and the only question that mattered was the oldest one in incident response: what happened, and who did it?

In Frontrow’s earlier life, this is where the story would have ended in a shrug — a frantic grep through application logs, a half-answer, and a postmortem full of “we believe.” But Frontrow had grown up over the course of this season. Every change in the system was an event, every event was kept, and — because Mara had started attaching context to them — every event carried who triggered it, which command caused it, and the correlation thread that tied it to everything else in the same chain of cause and effect.

So instead of guessing, Mara ran a query against the event log. Within minutes the picture assembled itself: a single deactivated admin account, a leaked API key, a script, one originating command, and 5,000 TicketRefunded events all sharing one correlation ID that traced straight back to it. Not “we believe.” This is exactly what happened, in order, with names and timestamps. The incident was still bad. But for the first time, it was completely knowable.

Why this is hard the traditional way

When something goes wrong, the most expensive question is “what actually happened?” — and most systems can’t answer it. They stored the result (5,000 tickets are now refunded) but not the story (who asked, through what, in what order, and why). The evidence is scattered across application logs that have already rotated, a database that only shows the current state, and the memory of whoever was awake.

So incident response becomes archaeology: reconstructing a timeline from fragments and hoping it’s complete. And without a way to link related actions — this refund, that login, those API calls — you can see individual dots but never the line connecting them. The answer you hand the customer (or the regulator, or the board) starts with “we think,” which is the worst way an answer can start.

How Relay changes the ending

This is the quiet payoff of everything Frontrow built. Because Relay stores an immutable event log and lets you attach rich metadata — the originating command, the user, causation and correlation IDs — to every event, the history isn’t just what changed but why and because of whom. And because the log is queryable, you can run a forensic scan over it during an incident without having built a special dashboard ahead of time.

// No pre-built report. Ask the log directly, after the fact.
var suspects = await eventLog
    .Scan(since: incidentStart)
    .OfType<TicketRefunded>()
    .GroupBy(e => e.Metadata.CorrelationId);
// 5,000 refunds, one correlation ID, one causing command, one user. Case closed.

The metadata turns “who did this?” from a hope into a field. The correlation ID turns 5,000 scattered events into one traceable chain. And the queryable log means you can investigate questions you never anticipated — the whole point of an incident is that you didn’t see it coming. Frontrow’s worst night became its clearest answer.

---

Frontrow started this season as a company that found out about its own problems from angry customers. It ends as one that can answer, precisely and provably, what happened inside its own walls. That’s the difference between software you operate and software that operates you.

What it costs you to ignore this

• “We think” is the most expensive sentence in an incident. Customers, auditors, and boards want “we know,” with evidence.
• Logs rotate; state forgets. The data you need to explain an incident is usually gone by the time you need it.
• Unlinked events hide the story. Without correlation, you see symptoms but never the cause.
• You can only answer questions you predicted. Pre-built reports can’t investigate the incident you didn’t see coming — a queryable log can.