DevOps project
Instrument an app and build an alert that actually fires
Metrics, a Grafana dashboard, and an alert rule proven to trigger by deliberately breaking the app — visibility that's tested, not just built.
The brief
Instrument a small app with metrics (request count, latency, error rate) using a Prometheus client library, run Prometheus and Grafana locally via docker-compose, build a dashboard showing those metrics, and set up at least one alert rule (e.g. error rate above 5% for 2 minutes). Break the app on purpose and confirm the alert fires.
Suggested stack
What you hand in
- A public GitHub repository with the instrumented app, compose file, and a README
- A screenshot or recording of the dashboard, and evidence the alert fired during a deliberate failure
- The README explains what each metric measures and the reasoning behind the alert threshold
Grading happens against the rubric below, so read it before you start — not after.
How this is graded
Published in advance and weighted out of 100. Nothing here is a surprise.
Metrics use the correct Prometheus type (counter for cumulative counts, gauge for a point-in-time value, histogram for latency distributions), and they measure something a real operator would care about.
The alert genuinely fires when the app is broken (proven, not claimed), and doesn't fire during normal operation.
A panel is understandable by someone who didn't build it, with labeled axes and a sense of what "normal" looks like.
docker-compose up brings up the full stack (app, Prometheus, Grafana) with dashboards and alert rules already configured, not manually clicked in afterward.
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- "We had no visibility into production" is one of the most common real incident postmortems, and this project builds the visibility and tests it.
- An alert that doesn't actually fire when it should is worse than no alert, because it creates false confidence — this is specifically checked by breaking the app on purpose.
- A dashboard that someone other than its author can read and act on is a real, transferable skill, not decoration.
Where people lose points
- Using a counter for a value that should be a gauge (or vice versa), so the resulting graph is nonsensical.
- An alert threshold with no stated reasoning, copied from an example rather than chosen for this app's actual traffic.
- A dashboard with panels but no sense of what "normal" looks like, so a viewer can't tell a spike from expected behavior.
Other DevOps projects
Two or three of these turn an empty resume into a portfolio.
Built it? Get it scored against this rubric.
Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.