How This Site is Built: Static Architecture for Zero On-Call Pages

When you spend your day job managing 120+ production services, Kubernetes clusters, and on-call rotations, the last thing you want is to get paged at 2 AM because your personal blog's database ran out of connections.

When I built jhern.dev, I applied the same reliability rule I use at work: remove every moving part you do not strictly need.

Static Export by Design

This site is built with Next.js using the App Router and TypeScript, configured with output: "export" so the entire application compiles down to static HTML, CSS, and client-side assets at build time.

There is no Node.js server running in production, no database to patch, and no API routes that can fail under load. Every blog post and project page is pre-rendered during CI and served straight from the edge.

Content as Code

Instead of wiring up a headless CMS with API keys and webhook rebuilds, all posts live right in the Git repository as .mdx files under content/blog/.

Treating writing like code gives me a workflow I already use every day:

• Every post is version-controlled in Git.
• A build step validates frontmatter metadata, compiles the MDX, and regenerates sitemap.xml and OpenGraph preview images automatically.
• If a build fails, broken markup never reaches production.

Trust, But Verify

Even a static site can break if DNS expires, a CDN edge misbehaves, or a bad deploy slips through. In the footer of every page on this site, you will see a live status badge powered by UptimeRobot running synthetic checks against jhern.dev.

This blog is where I share practical lessons on Site Reliability Engineering, Azure architecture, Terraform, Go tooling, and platform engineering. No fluff, just patterns that have held up in real production environments.