You're setting up the first CloudWatch alarms, a single-question dashboard, and the first operational response for a Lagos ride-hailing platform that has been running without alerts until a recent outage.
The discipline skills: choosing which services to alarm on, reasoning about alarm thresholds from an actual traffic baseline instead of round numbers, designing a dashboard that answers one question, wiring SNS notifications into a channel people actually read, and running through a provided runbook when an alert fires.
The AI-direction lesson: AI writes the Terraform for alarms, SNS, and dashboards competently. What it can't do is know that the matching service spikes to 95% CPU during Lagos rush hour -- so it defaults to 80% CPU and 90% disk every time, regardless of workload. It generates dashboards that tile every metric on one screen. It proposes remediation like "restart the service" without checking whether the service is actually running. The pattern from earlier projects -- AI defaults to the generic, plausible answer -- reappears here in an operational domain. This is the first project where AI brings the structural scaffolding and you bring the situational judgment.
Your Role
You're the cloud engineer. Chidi needs his platform to tell him when something is wrong, and his team to know what to do when it does. He has heard stories about teams drowning in alerts and ignoring all of them, and he doesn't want that to be his team.
Scaffolding holds steady. You still get a client message with gaps you need to ask about. What's different is the register. Until now the work has been building -- greenfield infrastructure, clean plans, new resources. This is the first project where you respond to something that's already running and breaks while you're watching. The shift from builder to operator is the point.
With AI, the pattern is now collaborative. You're not just directing it to produce artifacts and reviewing them for security defaults. You're feeding it context it can't infer -- rush-hour windows, which services Chidi actually cares about, how his team coordinates incidents -- and calibrating what it produces against that context.
What's New
Last time you built a CI/CD pipeline for a London agency and acknowledged that the pipeline will break and need maintenance. You treated maintenance as something that would happen later.
This time, maintenance happens. You build alarms, one of them fires during the project, and you work through it using a written runbook. Most of the job in cloud engineering is keeping things running. This project is the first taste of that.
Two things are genuinely new. First, alarm threshold reasoning -- choosing a number based on what "normal" looks like for this service, not what looks like a sensible default. Second, following a runbook -- verifying that the current situation matches the runbook's assumptions before acting, and recording what happened afterward in a way the next person can use.
The hard part: AI will suggest fixes that sound right. The runbook will propose steps that were tested against a real incident. When those disagree, you need to trust the runbook and be able to explain why.
Tools
- Claude Code -- directing alarm, SNS, and dashboard Terraform, drafting runbook content, suggesting remediation during the incident
- Terraform CLI -- alarms, SNS topics, and dashboards defined as code (from P1)
- CloudWatch alarms and dashboards -- new usage; CloudWatch metrics carry from P3
- SNS (Simple Notification Service) -- notification routing (new)
- AWS CLI -- alarm state checks and verification
- AWS Console -- visual verification of alarms and dashboards
- checkov -- security scanning on the Terraform you write (from P4)
- Git and GitHub -- version control, runbooks and incident reports in the repo
- VS Code + Terraform extension -- code editor
Materials
In the project folder:
- Chidi's Slack message (
first-contact.md) -- the triggering incident, what he wants, and the gaps you'll need to ask about. - Architecture summary (
architecture-summary.md) -- RideNaija's services, traffic patterns, and which services Chidi flags as critical, so you can design meaningful alarms without reverse-engineering an unfamiliar codebase. - Runbook (
runbook-matching-latency.md) -- the operational procedure for the alert that will fire during the project, written by a past on-call engineer. - Incident report template (
incident-report-template.md) -- placeholder sections for the report you'll write once the alert resolves. - Failure injector (
scripts/trigger-alarm.sh) -- a controlled, auto-unwinding script that stages the alert when you're ready for it to fire.
No alarm templates, threshold values, SNS wiring, or dashboard layouts are provided. You direct AI to produce those, and you decide whether the numbers it suggests match the workload.