Building my portfolio on Azure

A small website, real operational decisions

I wanted a home for my projects and learning, and a working system where I could practice SRE. A public website creates concrete questions: how do I review a change before visitors see it, identify the version in production, detect failures, and recover?

I kept the frontend as static HTML and CSS and used the delivery and monitoring systems around it to develop those skills. The project also has a strict $10 annual budget boundary, so monitoring must be deliberate and time limited.

How the website reaches a visitor

Cloudflare manages DNS, and Azure Static Web Apps hosts the public files and provides managed HTTPS. GitHub stores the source; GitHub Actions builds and deploys it.

During supervised exercises, an external availability test checks the public HTTPS path. Results flow into Application Insights and Log Analytics; KQL queries and an Azure Workbook evaluate the observations against my reliability targets.

The paid availability test stays disabled outside supervised exercises. Browser performance monitoring is also disabled in normal builds.

Make releases reviewable and recovery traceable

1. Change and validate. A feature branch and pull request run HTML validation, site tests, a sensitive-data check, a build, and a dependency audit.
2. Preview. The pull request gets a temporary Azure deployment through the DEV environment so the change can be inspected before release.
3. Approve production. Merging to protected main starts a PROD deployment that requires human approval. Deployment secrets are scoped to each environment.
4. Identify the release. A public deployment metadata file records the actual content commit and deployment time.

Recovery includes correcting the source

The emergency workflow validates an exact known-good commit from main before an approved rollback. Deployment metadata identifies the restored content even when the rollback workflow itself runs from a newer commit.

Restoring deployed files does not fix main. The recovery procedure also calls for a revert pull request and verification before normal releases resume, preventing the faulty change from being deployed again.

What the first monitoring exercise showed

The availability exercise captured ten checks between September 6 at 22:56:35 UTC and September 7 at 01:04:48 UTC, 2026. Those observations were later reviewed through the SLO Workbook.

Average duration was 508 ms, with a P50 of 409 ms and a P95 of 1,282 ms. Every check succeeded, but the sample did not meet the latency target. Availability alone did not describe the full experience.

Missing measurements remain unknown. Ten checks cannot establish a production trend or continuous 30-day SLO compliance. Periods when monitoring is disabled are not counted as successful service time.

Validate the measurement system too

On September 17 UTC, the deployed Workbook configuration matched its repository source and all five KQL queries executed successfully. This verified the configuration and query results; it did not verify the Workbook's visual rendering in the Azure Portal.

A separate time-boxed browser monitoring exercise produced three page views and three browser timing events. Closeout found no events after the cutoff, no user IDs, and no unsanitized URLs in the returned data. That is evidence from a limited exercise, rather than a claim about every possible browser session.

Lessons I am carrying forward

• A reachable page can still be slow. I need to investigate latency during the next supervised exercise before changing the target.
• Monitoring coverage is part of the result. A reliability percentage needs its sample size, collection window, and missing periods alongside it.
• Rollback and source recovery belong together. The deployed version and repository history must be brought back into alignment.
• Cost controls need concrete mechanisms. Budget alerts provide visibility; time-boxed exercises and an automation cutoff limit monitoring activity.

Next steps

I plan to investigate the observed latency, continue SLO and cost reviews, and work toward repeatable Terraform provisioning. A backend will be introduced when a portfolio feature needs it, giving the next layer of instrumentation a practical purpose.

Explore the engineering evidence

The source documentation preserves the measurement definitions, validation results, and recovery procedure behind this write-up.

• Architecture and request flow
• CI/CD and deployment metadata
• SLO definitions and measured results
• Browser monitoring exercise and closeout
• Production rollback runbook