---
title: "When the Customer Reports a Failure and Our Records Say Nothing Happened"
canonical: https://dxdev.com/everyday-ai/the-complaint-with-no-record-anywhere/
datePublished: 2026-07-21
---
A customer wrote in about a save that half-worked. He had added a helper to manage part of a shared scheduling tool for him. The helper tried to save some details and got an error. Some of what he'd entered stuck anyway, some of it didn't, and he ended up filling in the rest by hand. It read like a permissions problem: a new helper account and a partial failure, which is a familiar shape.

## Our own records showed nothing

The first thing we checked was our internal error records for that failure window. There was nothing. No trace of the save attempt arriving and failing. In a support investigation an empty record is usually bad news, because the easiest source of truth has nothing to say.

We didn't stop there. We reproduced the failure using the helper account itself, through a staff tool that lets support see exactly what a specific customer sees. The error came up on cue, screenshot and all. The [records for that window were still empty](/blog/the-silence-in-the-log-was-the-bug/). That emptiness pointed at the answer once we stopped treating it as a hole in the evidence and started treating it as a fact about what had happened.

## Three tabs, two of them wired up

The save screen could be reached from three places in the tool, three tabs showing different views of the same schedule. The save logic only recognized two of them. From the third tab it hit a dead end, showed a generic "something went wrong" message, and stopped without sending anything out at all.

That explained everything at once. The records were empty because there was nothing to record. No request ever left that screen, so there was nothing to fail on our end. It also explained the partial save that looked like a permissions problem. Edits made from the two working tabs went through fine. Edits made from the third tab hit the dead end every time, for anyone. We checked directly, and the account owner got the identical failure from that same tab.

## The fix

We connected the third tab's save action to the same working path the other two already used. We did not patch the dead end to fail a little more gracefully. Then we checked live, on the exact account and the exact save that had failed before, and it went through cleanly. The data that came back matched a snapshot taken right before the fix, so nothing had changed except that the request now actually fired.

## What the silence meant

When a customer reports a failure that leaves no trace anywhere in your own systems, it is tempting to doubt the report or assume your recordkeeping swallowed something. Neither was true here. Our records were fine. They correctly said nothing had happened on our end, because nothing had. A failure that happens before a request is ever sent leaves silence, and that silence told us to stop looking at what happened after the request arrived and start looking at what kept it from being made at all.