Not everything you track needs to ship to end users. A practical look at when to mark an entry internal-only, and when it should just stay public.
Not every merged pull request belongs on your public changelog. That's not a reason to skip tracking it — it's a reason to have a place for it that isn't the same list your customers read.
A security fix rarely needs a public writeup the day it ships — sometimes it needs the opposite, a quiet fix before anyone notices there was a problem. An internal refactor, a dependency bump, a rename that only your team will ever see the effect of — none of it helps a user understand what changed for them, and padding your changelog with it just makes the entries that do matter harder to find.
The opposite failure is just as common: treating "not for customers" as "not worth writing down." Six months later, nobody remembers when a given security patch actually landed, and there's no record to check. The entry was worth writing — it just wasn't worth publishing.
The simplest fix is giving every entry a visibility flag alongside its category, rather than maintaining two separate changelogs. Buoylog's entries default to Public, and switching one to Internal only keeps it out of the public changelog page, subscriber emails, and the embeddable widget — while it still shows up wherever your team actually needs to see it, including a project's preview link.
Try the visibility toggle
Mark any entry Public or Internal only, right from the same form you already use to categorize it.
Start free trial →If a user would ask "wait, what does this mean for me" after reading an entry, it's probably public. If the honest answer is "nothing, this was for us," mark it internal and move on — the record exists, it just isn't taking up space in front of the people it wasn't written for.