Cloud and Observability Planning

What it is: the plan for what the business runs on, what it watches, what wakes someone up, and what that costs - written before any of it is bought.

Overview

Works out the smallest monitoring plan that would actually catch this business's worst failure, then builds it only when asked. The default output is a short recommendation, not a service register. The register - CSV, SQL DDL, JSON Schema, Notion mapping - is produced on request, from one field list so the four cannot drift apart.

Layer: Layer 8: Operate. Fits: Growth stage. Table code: n/a.

The rule this table exists to enforce: an alert is a human cost, so Alert Channel and Severity decide whether a person is woken at 3am. Everything else in this table exists to make that decision possible: what the service does (SLI Definition), what good looks like (SLO Target), what is measured (Dashboard URL), what it costs (Monthly Cost Estimate), and - the field most tables leave out - what happens when the alert fires (Runbook URL). An alert with no runbook converts a technical problem into a panicked one.

The second rule: Phase is the field that keeps this affordable. A ten-service stack with four signals each, on a plan tier, ordered by what would hurt the business most. A business with no developer should be running a managed platform and three alerts, not a stack of collectors.

When to Use This Skill

• monitoring, observability, alerting, uptime, "we found out from a customer"
• SLI, SLO, error rate, latency, p95, p99
• "what should we watch", "how do we know the site is down"
• incident response, on-call, runbook, postmortem
• cloud cost, what is it costing, what should we turn off
• "which service should we use", VPS, containers, serverless, managed hosting
• incident readiness, status page, downtime prevention

Do not use it for: application code, infrastructure as code, or a deployment pipeline (devops-pipeline-designer, ci-cd-pipeline-builder in the engineering pack); a security architecture review (security-and-privacy); or a real incident, which is a live situation, not a plan.

How It Works

Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.

Step 1 - Identify intent

Read the request and pick the intent before asking anything.

• "plan" / "set up" / "we need" -> artifacts wanted; go to Step 2.
• "the site is down" / "is it down" / "we are down" -> an incident, right now. Confirm the user-facing failure first and point at the runbook; do not build anything.
• "what does this cost" / "review" / "audit" -> a review, not a build.
• "should we use" -> a decision question; answer with trade-offs, then offer the register.

Ask only if this is the highest-value missing fact; otherwise proceed without an opener:

Q: What breaks for the business if the site or app is down for one hour, and who would notice first - a customer, a member of staff, or an automated system?

Step 2 - Ask only what is missing

Treat ambiguous replies as unanswered and ask which explicit option the user means. Record unknown values as Unknown; Unknown is not zero. A record must not be Done when a required check fails.

Skip anything already answered. Ask the rest one at a time, and stop as soon as the remaining answers would not change the plan.

• Failure - What is the business-critical thing - the website, the booking form, the till, email, the file uploads? / What is the worst realistic failure - down, slow, wrong data, or an email that silently stops arriving? / How long is a customer willing to wait before they complain, and how long before they leave?
• Stack - What is actually running today - shared hosting, a VPS, a managed platform, a SaaS tool, containers? / Who set it up, and is that person still available? / Is there a repository, and who can deploy?
• Traffic - Roughly how many visitors, orders or jobs a day? / Any seasonal or campaign peaks that change it by an order of magnitude? / Are there peak periods where being slow is worse than being down?
• People - Is there anyone who can be on call, and at what hours? / Does someone already use a tool the business pays for? / Who is allowed to restart something at 3am?
• Data and money - What must not be lost, and what is the acceptable recovery point? /

…