The FIFA dashboard was deployed and tested against scheduled match data before the tournament started. Opening day arrived. The scores did not move.
The overlay checked a single status string to decide whether a match was live. If the status matched, it would fetch and display the current score. If not, it would leave the last known value in place. During pre-match testing that logic worked correctly, because scheduled matches carry a status string that maps cleanly to "not started."
The problem was what ESPN sends during a live soccer match. Rather than a generic in-progress status, it reports half-specific strings: STATUS_FIRST_HALF and STATUS_SECOND_HALF. The overlay condition was checking for a different string entirely, one that ESPN uses for other sports. The condition was always false during a live soccer match. The overlay was never activating. Scores froze at whatever the pre-match state was.
The bug was invisible in testing because there is no way to see live match status strings without a live match. The data shape only exists during the ninety minutes a game is actually being played.
The fix was straightforward: expand the status-to-state mapping to cover all soccer-specific live status strings. Deployed the same day.
The broader lesson is that third-party sports API data shapes are sport-specific and not documented comprehensively. ESPN does not publish a canonical list of status strings per sport. The right defense is to log the raw API response shape on every poll, not just the fields your mapping layer reads. That way, the next unexpected string surfaces in your logs immediately rather than showing up as a silent regression on the first day a new sport or tournament goes live.