Runtime · Pro and up
Noah
Noah’s job is to watch the health of what the company runs in AWS, and say what changed when something breaks.
On this page
What Noah does
- The health of the AWS resources chosen for each project, from their CloudWatch metrics
- Alarms that are firing or fire often, and log groups kept forever
- Incident updates and postmortem drafts, with a timeline of what changedStudio
- A first look minutes after a CloudWatch alarm firesStudio
- A monthly review of noisy, silent and missing alarmsStudio
- Errors and load compared before and after each production deployStudio
- The date each database runs out of diskStudio
- Lambda concurrency, database connections and service quotas against the account’s real limitsStudio
- Whether a resource is in use, from its traffic
What you can ask
You ask Grant, and he brings in Noah for questions like these.
- “Is anything unhealthy in production right now?”
- “Write a postmortem for yesterday’s outage.”Studio
- “Which alarms notify nobody?”Studio
- “What changed before the API errors started?”
What you get
Errors on the orders-api Lambda rose from under 0.1% to 6% two minutes after a deploy and a change to its IAM role. Likely cause, not verified: the role change. CloudWatch has no metrics for the queue worker, so its health is unknown.
What Noah reads
- AWS runtime metrics
- AWS inventory
- AWS changesStudio
- GitHub deliveryStudio
- AWS quotas and limitsStudio
- AWS running resources
When Noah works
At each scheduled check-in and when you ask Grant.
What Noah may do
Read-only: reads the approved sources and reports findings.
What Noah never does
- Call missing metrics healthy or idle
- Restart, roll back or experiment on anything
- State a likely cause as fact
