domains / families / devops / observability-cloud-planning
observability-cloud-planning
authentic
Build a cloud, SLO, and incident-readiness register after intake. Use when an SME needs monitoring scope, alert ownership, cost limits, or service planning.
When to use
- 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
When not to use
- This is a plan. It does not deploy anything, install an agent, open a dashboard, create an
- It has no access to the business's infrastructure, so it cannot measure a baseline, read a
- Costs are estimates by definition and depend on region, tier, retention and traffic that
- It does not recommend a specific provider on a current price. Provider capabilities,
- Log volume, cardinality and ingestion cost are the usual cause of an unexpected bill, and
- It cannot tell you what is currently running, what is currently alerting, or whether the
- Uptime, latency and error-rate targets are engineering commitments. They are not
- SLOs do not replace a backup, a restore test, or a disaster recovery plan. A monitored
Skill page
Source