The engineering notebook
Beacon: build an SSL and uptime monitor in Go
Starting with no Go and no networking background, you finish able to resolve a name, open a connection, complete a TLS handshake, read a certificate's expiry, send a request, bound all of it with one deadline, and run many checks at once without leaking anything.
Your learning trail
Verified project-agent submissions only. Reading or clicking cannot unlock progress.
System design
What you are building
The prober turns one target into one measured result. A name is resolved to addresses, a TCP connection is opened and timed, TLS is negotiated and the certificate chain inspected, an HTTP request is sent and its status and latency recorded — and the whole journey happens inside a single deadline, so no check can ever run forever. A failure at any layer is classified by the layer that produced it rather than flattened into one unhelpful error.
Stages
10 stages, in order
Expand any stage to read what it teaches. A stage opens for work once the stage before it passes a verified submission.
Phase 1 — One check, one answer
Make a single request succeed and fail deliberately, and understand what each network layer contributes to the answer.
One request, one answer45 minutes (locked)
What does it actually mean to say a website is up?
You will be able to create a Go module in your fork whose path ends in /beacon.
Fork the project repository to start working through the stages.
Resolve the name first75 minutes (locked)
What really happens before a program can connect to a hostname?
You will be able to keep the module path and cmd/beacond binary created in stage one.
Fork the project repository to start working through the stages.
Open the TCP connection80 minutes (locked)
What does a successful connection prove before HTTP exists?
You will be able to keep the explicit DNS lookup from stage two and print its duration and returned addresses.
Fork the project repository to start working through the stages.
Phase 2 — The secure channel
Complete a TLS handshake yourself, read the certificate chain it produced, and turn an expiry date into a warning worth acting on.
Negotiate TLS90 minutes (locked)
How does a client know it is speaking securely to the right server?
You will be able to keep the DNS resolution timing and the TCP connect timing from the previous stages.
Fork the project repository to start working through the stages.
Read the certificate clock75 minutes (locked)
How does a monitor know a TLS certificate is about to expire before users find out?
You will be able to keep the stage-four flow intact: resolve DNS, dial TCP, complete the TLS handshake and print the existing timings.
Fork the project repository to start working through the stages.
Phase 3 — A check you can trust
Send the request over a client you control and put the whole journey under one deadline, so every check has a worst case you can state.
Measure the HTTP answer80 minutes (locked)
Once the secure connection exists, what exactly counts as the server's answer?
You will be able to keep the existing DNS, TCP, TLS and certificate-expiry output from stage five.
Fork the project repository to start working through the stages.
Put the whole check on a deadline85 minutes (locked)
How does a prober guarantee that one slow target cannot run forever?
You will be able to create one end-to-end context for each check with a five-second timeout and call defer cancel() immediately after creation.
Fork the project repository to start working through the stages.
Phase 4 — From script to prober
Turn printed text into structured, classified results, check a whole list concurrently without harming the targets, and extract it all into a package the rest of Beacon can import.
One structured result75 minutes (locked)
How does a monitor record a check so another system can store, query and trust it?
You will be able to define a Result struct in cmd/beacond/main.go carrying the target URL, UTC start time, total duration, DNS duration, TCP duration, TLS duration, HTTP duration, HTTP status, certificate expiry, failure stage and error text.
Fork the project repository to start working through the stages.
Many checks without self-inflicted outages90 minutes (locked)
How can a monitor check many targets at once without becoming the outage it is trying to detect?
You will be able to replace the single hard-coded target with a small hard-coded slice of HTTPS targets.
Fork the project repository to start working through the stages.
A prober package with a clean API90 minutes (locked)
How does a working script become a package that the rest of Beacon can safely call?
You will be able to create internal/prober and move the target, result, failure and check logic out of cmd/beacond/main.go into that package.
Fork the project repository to start working through the stages.
About this path
Expired certificates and silent outages are among the most embarrassing and most preventable production failures there are, and the tools that catch them are treated as magic. They are not. This course takes the magic apart one network layer at a time.
What you will learn: Go networking, TLS handshake, SSL certificate expiry monitoring, DNS and TCP, Context deadlines and concurrency. Build the project through cumulative challenges with beginner explanations and local verification.
- Level
- Complete beginner to independently building and operating the project
- Format
- 10 cumulative stages. Every stage teaches the concept in full before any code, then gives you the thing to build and the run that proves it works
- Before you start
- No Go, networking or TLS experience is assumed. You need a terminal, an editor, Git, and Go 1.22 or newer. Everything runs locally against public endpoints and a local test server; no cloud account and no credentials are required at any point.