The Log Test: What Your Software Quietly Writes Down About Your People

A front desk coordinator gets an invite to the practice calendar.

The invite fails. Someone retries it, it goes through, and the day moves on. Nobody thinks about it again. But somewhere behind the screen, the software wrote a line about that failure. And that line may hold her email address, sitting in a log file that people outside your practice can read and that nobody at your practice will ever open.

That is not a scandal. It is a habit. Most software keeps a running diary of what went wrong, and most of it was written by people in a hurry.

This Issue of The Unburdening names a Log Test for independent and small-group practices: when your software writes down what happened, does it write down your people too?

The diary nobody reads

Logs exist for good reasons. When something breaks, the people who maintain a system need to know what broke, where, and when. A practice tool without logs is a practice tool nobody can fix.

The trouble is what drifts into them. An error message that repeats the address it failed to reach. A crash report that carries the raw text of whatever was on the screen. A routine job that prints the name of the practice it just touched. None of these were decisions. They were defaults.

Behavioral health practices think hard about client records, and they should. The quieter question is what the system records about the staff who keep the practice running: clinicians, billers, front desk, owners. Those people trusted the practice with their work email. They did not agree to have it copied into places they will never see.

The Log Test

Ask whoever maintains your practice software, or look for yourself if you can. Score each answer: solid, workable, or brittle.

1. Ids, not identities. When the system notes who did something, does it use an internal id, or a person's email address or name?

2. Errors without names. When an outside service fails and sends back an error, does the system pass that error straight into the log, addresses and all, or strip them first?

3. Crashes without contents. When the app crashes or a request fails, does the report keep what an engineer needs (where it happened, what kind of failure) without the raw message that may hold personal details?

4. A sweep you can repeat. When one leak is found, does anyone go looking for the others, and is there a test that would catch the same leak coming back?

If any one of those four is brittle, the system is spending trust quietly, even if nothing bad has happened yet. Logs tend to outlive the people who wrote them.

The earlier tests still apply

The Presence Test asks whether a tool reduces cognitive load at the moment of care. The Front Door Test asks whether a client can find the next step. The Update Test asks whether every change earns trust. The Draft Test asks whether work in motion stays put. The Claims Test asks whether getting paid protects the room. The Access Test asks whether a person who cannot be seen stays connected. The Waitlist Test asks whether offering a spot keeps the person waiting small. The Count Test asks whether a number survives an edit. The Receipt Test asks whether proof of payment reaches the right hands. The Assignment Test asks whether a shared chart keeps each person's work their own.

The Log Test is the only one about a screen nobody at the practice ever sees. That is exactly why it needs asking.

Holding ourselves to it

We should be graded by the same four questions, so here is a recent example of our own instead of a hypothetical.

While checking a Practice OS change in our staging environment, we noticed that two calendar warning lines printed a staff member's email address into our server logs. The error that came back from the calendar service repeated the same address. Nobody outside the team saw it, and it was not client information. It was still a gap, and we ruled on it plainly: our logs should not carry staff email addresses.

A Practice OS release that is now live in production changed that. Calendar log lines now identify a person by an internal id instead of an address. Every calendar log line also strips out any address left in an error message, and the underlying error no longer names the person to begin with. That is the first two questions.

Then we went looking for the rest. The same release closed similar leaks in failed invite and payment link emails, in crash reports sent from the app, and in the catch all handler for failed requests, which now keeps the route and the code location but not the raw message. AI follow up failures now log ids and the type of error only. Push notification refusals no longer log device tokens. A nightly routine job no longer prints the practice name. Tests now check that the fixed paths write no email addresses at all. That is the third and fourth questions.

Here is the honest limit. This was an ops change, so there is nothing new to see on any screen, and you have to take our word for what the logs now hold. It also is not finished. A couple of older email paths still use their own address scrubbing and are queued to move onto the shared one. We would rather say that plainly than call it done.

Run the four questions on that change and the grade is solid on the first three for the paths we fixed, and workable on the fourth until that follow up lands. If a future change of ours fails one of the four, the test should catch it, and we would want to hear about it.

What good looks like (without theater)

You do not need a security team. You need a few plain questions and a vendor willing to answer them.

Ids, not identities: the log says which account, not whose inbox.

Errors without names: an outside service's complaint gets cleaned before it is written down.

Crashes without contents: the report says where it broke, not what was on the screen.

A sweep you can repeat: one leak found means a search for the rest, and a test that keeps it fixed.

Wherever the answer is "we have never looked," that is the design problem. Not a staff problem.

What to audit this week

Pick one tool your practice uses every day. Ask the vendor, in writing, whether staff email addresses or names appear in their application logs, and how they would know.

If nobody can answer, that is your first score.

Strengthen the brittle ones first. Tool shopping second.

Coordination is the product

EMILE-E builds for the practice side of this reality. Practice OS is meant to keep operational truth coherent so scheduling, notes and billing stop living as separate improvisations, including the parts of the system nobody at the practice ever opens. VibedIn and Sesh sit in that same family when the practice chooses them.

If a soft next step is useful: Practice OS is $89 per clinician per month. VibedIn is $49 per practice per month. Sesh is $10 per clinician per month.

Closing

The people who run a practice deserve the same quiet care as the people it serves.

Ids, not identities. Errors without names. Crashes without contents. A sweep you can repeat.

Score the four. Strengthen the brittle ones. Keep your people out of the diary.

That is how a system keeps the trust it was given, even where nobody is watching.

The Unburdening is EMILE-E's practice-side letter on building mental health infrastructure that holds. Quiet coordination over tool sprawl.