Your application is live. Since Week 11 it has a public URL, and since last week every merge deploys itself. Anyone in the world can send it a request at any moment — including the moment you are asleep.
Now imagine Monday morning. A user messages you: "The app was broken all weekend." Your whole debugging toolkit wants to know: broken how? Which request? What input? And your strongest habit — set a breakpoint, step through the code — is suddenly useless. There is no IDE attached to a container running in a data centre somewhere, and the failing moment happened two days ago. You cannot pause production, and you cannot rewind it.
This is the gap this week closes. In production, your application must report on itself — while it runs, without being asked, in a form you can search later.
Observability is how you understand a system you cannot pause, debug, or step through — which is every system once it reaches production. It is one of the clearest lines between a junior who can write code and a developer a team trusts to run it.
A system is observable when you can answer the question "what is it doing, and why?" from the outside — from the signals it produces.
https://www.youtube.com/watch?v=TQur9GJHIIQ
You have already practised a primitive form of it. When a deploy failed in Week 11, what did you do? You opened your hosting platform's Logs tab. That reflex — something is wrong, check what the app said — is observability. This week we sharpen it from "scroll through the platform's log page and hope" into a professional workflow.
💬 Think back: what was the last problem you solved by reading logs instead of using the debugger? What made the log line useful — or useless?
Professional teams talk about three kinds of signals a system can emit. Each answers a different question:
<aside> 💡
Metrics tell you that (something is wrong), logs tell you why, traces tell you where.
</aside>
There are few big players in the market that provide observability tools. They all do variations of the same job: collect signals, let humans search them.
Your hosting platform already shows your logs, so why is this a whole week? Because the built-in log page has real limits, and every platform's does:
The professional answer is to make logs leave the server and live in a dedicated tool built for searching them. That is called centralised logging, and it is the heart of this week.
First you learn to write logs worth reading, and to keep secrets and personal data out of them. Then you make those logs machine-readable, ship them to Grafana Cloud so they survive anything that happens to your container, and learn to hunt through them like a detective. Finally you give your deployment a proper health check and build your first dashboard.
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.