"The record could not be saved safely. Nothing was reported as completed" - I cannot save any gig edits

You open a gig, add the buyer's name, email and phone, press Save, and the app answers "The record could not be saved safely. Nothing was reported as completed." You try a different gig and a different field, and it does the same thing. The way performers describe it to us is blunt: "it won't let me save" and "I can't save any edits to gig records right now, including adding buyer contact info." This article explains what that message really means, why it is not what it sounds like, and the three things that actually cause it.

First, the theory this message plants in your head is wrong

The wording sends nearly everyone to the same place. The bug report that produced this article put the theory plainly: "no gig in my account has a show completed milestone yet", so the natural next question is "is the save logic checking for a completed gig before allowing any save" and refusing everything until the first show is marked done.

It is not. There is no rule anywhere in Booked Solid that requires a completed show, a show completed milestone, or any other milestone before it will let you save a gig. Support read the save code line by line to be certain of that.

The next instinct is usually to fill in more fields to satisfy the imagined requirement - buyer name, event date, deal stage, deposit paid date, fee amount and currency. It is a dead end. Those fields were never the problem, and you can put in as much or as little as you like. Skip that step.

The old sentence "Nothing was reported as completed" was badly worded on our end. All it ever meant was this: the save itself did not complete, so the app rolled it back and changed nothing.

What actually happens when you press Save

The original bug report was titled "Gig record save blocked", and that is exactly right. The save was blocked, on purpose, by a safety check.

When you save a gig, the app writes the new version to a temporary file first, immediately reads that file back to confirm every character landed exactly, and only then swaps it in over your record. If it cannot prove the read-back, it refuses the save and puts your record back precisely as it was, rather than risk a half-written file replacing good data.

Two things follow from that, and both are worth knowing before you start hunting:

• Your data is never at risk. A blocked save is a save that was thrown away cleanly. Nothing was half-written and nothing was lost.
• The failure is uniform by nature. If the machine cannot write and read back a small temporary file, it cannot do it for any gig or any field, so the error follows you everywhere. That pattern is a clue about the machine, not about a particular record.

Cause 1: the disk is full

This is what it turned out to be in the reported case, and it is the one to check first even though it is the least obvious. The support bundle showed the save failing with ENOSPC: no space left on device in two different places on the same volume: the temporary write inside Booking HQ (_config/automation-jobs.json.tmp) and the app's own settings.json.tmp in its application support folder. Two unrelated locations failing the same way is the tell that the whole disk is out of room, not one folder.

Writing that temporary copy needs free space. When the volume is critically low, the write fails, the app rolls back, and every save fails identically.

1. Free up space on the drive your user folder lives on. On a Mac, check Apple menu > About This Mac > More Info > Storage, or System Settings > General > Storage on newer macOS.
2. Aim for at least a few GB free, more if you can spare it.
3. Try the save again. It should go straight through.

"But I have terabytes free"

The app is not deciding you are out of space. It is repeating what the operating system told it at the moment of the write. On a Mac, the number you see in Finder can mislead you in two specific ways:

• Purgeable space. macOS counts space it intends to free later, mostly local Time Machine snapshots and caches, as Available. So Finder can show a large free number while the volume is genuinely full at the instant something tries to write. This is the most common version of this problem.
• The free space is on a different drive. Your Booking HQ and the app's own files both sit on your startup disk, and the temporary copy is written right beside the record it is replacing. Room on an external or second drive does nothing for these saves. Only the startup disk counts.

Restart the Mac first. That on its own often releases stuck purgeable space, and it is the simplest move, so do it before anything else. Then check the real number: open Disk Utility (Applications > Utilities), select your startup volume (usually Macintosh HD - Data), and read Available along with how much of it is marked purgeable. If you are comfortable in Terminal, df -h / tells you the same thing in one line.

A full disk also blocks the app from updating

This one catches people out, so it is worth saying plainly: the installer needs room to unpack the new version. On a full disk the update downloads, fails to unpack, and quietly leaves you on the old build. That is why you can click update, restart, and still be reading the same old wording afterwards. Free the space first, then update.

Cause 2: your Booking HQ is not a plain local folder

The app needs a plain local folder it can write to and read straight back. These locations break that:

• A synced or cloud folder: OneDrive, Dropbox, or Google Drive. The sync client can grab the file at the exact moment the app writes it.
• A network or mapped drive, for example a lettered drive such as the Z: drive.
• A symlink or reparse point pointing somewhere else.

1. Open Settings > General and scroll to Your Booking HQ. The path readout shows the exact folder the app is using right now, with a Change button beside it.
2. Read that path. If it contains OneDrive or Dropbox, or is a lettered network drive, that is very likely your whole answer.
3. Use Change to point Booking HQ at a plain local folder directly under your user folder, outside any sync folder. Alternatively, pause sync on the existing folder.
4. Try the save again.

Now the honest part. In the reported case this was support's first theory, and it was wrong. That customer's Booking HQ was /Users/<name>/BookingHQ, already a plain local folder, and a round of email was spent on it before the support bundle named the real cause. Check the path, it takes a few seconds, but if it comes back clean do not stop here. Go back to cause 1.

There is more on this folder, including how to find a lost one and restore a backup, in Your Booking HQ folder: change it, find it, restore a backup, tune it up.

Cause 3: antivirus is holding the file mid-save

Security software that uses controlled folder access, ransomware protection, or aggressive real-time scanning can hold the file for a beat during the write, which is long enough to fail the read-back. If you run antivirus beyond what came with your operating system, allow Booked Solid through its controlled folder or ransomware protection, then try the save again.

The message changed: check which version you are on

If the sentence on your screen still reads "The record could not be saved safely. Nothing was reported as completed.", you are on an older build.

• 1.10.1 reworded the message for both a gig save and a stage change, so it says plainly that nothing was changed and surfaces the real reason on screen. A repeat of this exact failure now shows the actual cause, in that case no space left on device.
• 1.10.2 added a full disk to the plain-language hint. Before that, the hint listed OneDrive, Dropbox, network drives and antivirus only, which is precisely what misdirected disk-full users.

On 1.10.2 or newer the message reads "The record could not be saved, so nothing was changed." followed by "Reason:" and the real error, then a hint to check that your disk is not full, that your Booking HQ is a plain local folder, and that antivirus is not locking it. That one line usually ends the guessing.

Update at booked.kivimedia.co/download. If the update will not land, read cause 1 again, because a full disk is a common reason an update never installs.

Get the exact reason: send a support bundle

If you would rather not work through three causes by hand, skip to the evidence. In Settings > General, scroll to Support logging and click Generate Support Bundle. It gathers app errors and safe system details with your client data redacted, so no names, emails or notes leave your machine. That bundle is what named no space left on device in the reported case, after a round of guessing had already gone the wrong way.

Attach it to a ticket with two or three sentences about what you were trying to save. Full instructions, including how to turn on detailed logging first, are in Generate a support bundle and turn on support logging.

A gap we know about

The app should notice at the moment you pick a Booking HQ folder that it is synced, on a network drive, or a symlink, and warn you then, instead of accepting it and failing every save later with an opaque message. That is on our list. Until it ships, cause 2 above is the manual version of that check.

If it still will not save

Send a fresh support bundle once you can confirm all four of these: the startup disk genuinely has room to spare, your Booking HQ path is a plain local folder, antivirus is allowing Booked Solid through, and you are on 1.10.2 or newer. By then the app names the reason on screen, so copy that line word for word into your ticket. It is the single most useful thing you can send us.

Still stuck? Email bookedsolid@kivimedia.freshdesk.com and a person will help.