When was your site last deployed? What code is actually running right now?
These are questions I couldn't answer reliably for years. I'd deploy a change, and a week later someone would ask "when did that feature launch?" I'd have to dig through git logs and CloudWatch timestamps, piecing together fragments until I figured it out.
It's a surprisingly common problem. Most platforms hide their deployment history behind opaque dashboards. You click "Deploy" and hope for the best, but you never really know what's running.
The Problem with Mystery Deployments
When you can't trace your deployments, you lose visibility into your own site.
Debugging becomes a nightmare. A user reports a bug that started last Tuesday. Did it come from your code or theirs? You check git blame, but when exactly was that commit deployed? Without build history, you're guessing.
Changes become untraceable. Your site looks different than yesterday, but you're not sure why. Was it a styling tweak from last week? A recent update? An old test that never got rolled back?
Trust evaporates. When you push changes to production, how confident are you that the right code is running? Most developers have this lingering fear that old code is somehow still executing.
Auditing is impossible. If you're serious about your platform, you need to know: who changed what, when, and why. Without build tracking, that audit trail doesn't exist.
How Jottings Solves It
Every time your site is built and deployed, Jottings records the exact Git SHA that generated that build.
When you visit your site, there's an invisible metadata tag embedded in the HTML. It says: "This site was built from commit a3f2e9d on 2025-12-06 at 14:32 UTC."
You can see this by viewing the page source and looking for the meta generator tag (or just asking support). That commit ID is your truth. It's the single source of truth for what's actually running.
What This Gives You
Instant debugging. A feature seems broken? Check the build version, then run git log a3f2e9d..HEAD to see exactly what's changed since that build. Is the bug in code that was added after this build? Then it's not your fault—something else broke it.
Deployment confidence. When you push a change, you can verify it's actually deployed by checking that the site's build version matches your latest commit. No more wondering if the cache is stale or old code is lingering.
Audit trails. "When was that section changed?" Just check the build version and trace it back to the commit message. You have a complete history.
Rollback clarity. If something goes wrong, you can see exactly which commits are in the current build and roll back with precision.
Under the Hood
This is dead simple to implement, which is probably why more platforms don't do it.
When your site is generated, the build system captures the Git SHA. It embeds this in an HTML comment or meta tag. That's it.
No complex versioning schemes. No semver debates. Just a Git hash that proves where your code came from.
The best part? It costs nothing. Git already gives you this information for free. You're just making it visible.
The Longevity Angle
I think about Jottings as a platform for lasting websites. Part of that is building in transparency.
If you export your site in 2035, you'll have a folder of HTML files. Will you know what version they are? If every file contains a build timestamp and Git commit reference, you'll have a complete historical record.
That's the difference between a website that's yours and a website that belongs to a platform. When you own it, you know every detail about it. The builder doesn't get to hide information from you.
Try It Yourself
If you're using Jottings, open your site right now and check the page source. Look for the generator meta tag. You'll see the exact commit that built your site.
This is the kind of transparency I think every platform should offer. You deserve to know what's running on your behalf.
Start with Jottings and get full visibility into your deployment history. Because sites are meant to last, and lasting sites need to be auditable.