How presets work
Presets don't name your resources, so they work in any account. They use metrics AWS publishes for the whole account, such as Lambda's totals across every function, or a SEARCH expression that finds every function, instance, table or queue there is. The alarm presets cover every alarm in the region.
- Add one with Create Widget › Preset on the Widgets tab (see Create a widget). Search presets matches names and descriptions.
- Region: presets look in the account's default region, unless you choose another under Region in the preview, and keep the region they were added in, even if you change the account's region later. Each region is a widget of its own. The Cost presets and CloudFront requests always use US East (N. Virginia),
us-east-1, the only region with those metrics. - Title: rename a preset in the preview if you like, or later with Rename in its More menu (⋯). Over another time range than its own, its title says which, such as “Lambda invocations, last 7 days”.
- Permissions: metric presets need
cloudwatch:GetMetricData, and the alarm presetscloudwatch:DescribeAlarms, both in CloudPeek's policy.
Cost
| Preset | What it shows | Shown as | Time range |
|---|---|---|---|
| Month-to-date spend | Estimated charges so far this month, or over the time range you choose. Needs CloudWatch billing alerts turned on in the Billing console. | Number and sparkline | Month to date; or 3 days to 30 days |
| Month-end forecast | What this month will cost if spending carries on as it has so far. High in the first days of a month, when charges billed on the 1st look like a daily rate. | Number and sparkline | Month to date; or 3 days to 30 days |
| Spend and forecast | This month's estimated charges so far, and the month-end forecast they make settling as the month goes on. | Graph | Month to date; or 3 days to 30 days |
| Daily spend | What you spent on each of the last 7 days, a column a day. Needs CloudWatch billing alerts turned on in the Billing console. | Columns, one a day | Last 7 days; or 2 weeks, 30 days, or month to date |
| Spend by service | This month's estimated charges for each AWS service, biggest first. | Bars | Month to date only |
| Spend share | Each service's share of this month's estimated charges. | Donut | Month to date only |
| Spend trend | Estimated charges over the last 30 days, climbing through each month. | Graph | Last 30 days; or 3 days to 30 days, or month to date |
Compute
| Preset | What it shows | Shown as | Time range |
|---|---|---|---|
| Lambda invocations | Invocations of all your Lambda functions together. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Lambda errors and throttles | Errors and throttles across all your Lambda functions. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Lambda error rate | The percentage of Lambda invocations that failed. | Number and sparkline | Last 3 hours; or any from the last hour to the last 30 days |
| Lambda duration | Typical (p50) and slowest (p99) Lambda run times, in milliseconds. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Lambda concurrency | The most Lambda functions running at once, against your account's concurrency limit. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Lambda errors by function | Which Lambda functions failed in the last 24 hours. | Bars | Last day; or any from the last hour to the last 30 days |
| EC2 CPU by instance | CPU utilization of each EC2 instance. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| EC2 average CPU | The average CPU utilization of all your EC2 instances, as a gauge. | Gauge | Last 3 hours only |
| EC2 CPU summary | Each EC2 instance's latest, lowest and highest CPU utilization, as a table. | Table | Last 3 hours only |
| EC2 network traffic | Network traffic in and out of all your EC2 instances, in bytes. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| EC2 failed status checks | How many EC2 instances are failing their status checks. | Number and sparkline | Last 3 hours; or any from the last hour to the last 30 days |
| ECS service CPU | CPU utilization of each ECS service. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| ECS service memory | Memory utilization of each ECS service. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
Databases
| Preset | What it shows | Shown as | Time range |
|---|---|---|---|
| DynamoDB capacity used | Read and write capacity consumed by all your DynamoDB tables. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| DynamoDB throttles | Reads and writes DynamoDB throttled across all your tables. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| RDS CPU by instance | CPU utilization of each RDS database instance. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| RDS connections | Open connections to each RDS database instance. | Bars | Last 3 hours only |
| RDS free storage | Free storage left on each RDS database instance, in bytes. | Bars | Last 3 hours only |
Storage
| Preset | What it shows | Shown as | Time range |
|---|---|---|---|
| S3 bucket sizes | The size of each S3 bucket in this region, updated daily. | Bars | Last 3 days only |
| S3 object counts | How many objects are in each S3 bucket in this region, updated daily. | Bars | Last 3 days only |
Messaging
| Preset | What it shows | Shown as | Time range |
|---|---|---|---|
| SQS messages waiting | Messages waiting in each SQS queue. | Bars | Last 3 hours only |
| SQS oldest message age | How long the oldest message in each SQS queue has waited, in seconds. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| SNS failed notifications | Notifications SNS couldn't deliver, across all your topics. | Number and sparkline | Last 3 hours; or any from the last hour to the last 30 days |
| Step Functions failures | Failed Step Functions executions, across all your state machines. | Number and sparkline | Last 3 hours; or any from the last hour to the last 30 days |
Web traffic
| Preset | What it shows | Shown as | Time range |
|---|---|---|---|
| Load balancer requests | Requests to all your Application Load Balancers. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Load balancer 5XX errors | Server errors from your targets and from your Application Load Balancers themselves. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Load balancer requests and errors | Requests to all your Application Load Balancers, with their targets' server errors on a scale of their own. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Load balancer p99 response time | The slowest (p99) response time of each Application Load Balancer's targets, in seconds. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| Slowest load balancer p99 | The p99 response time of your slowest Application Load Balancer's targets, in seconds, on a gauge up to 1 second. | Gauge | Last 3 hours only |
| API Gateway requests and errors | Requests and errors across all your API Gateway REST APIs. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| API Gateway p99 latency | The slowest (p99) response time of each API Gateway REST API, in milliseconds. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
| CloudFront requests | Requests to all your CloudFront distributions. | Graph | Last 3 hours; or any from the last hour to the last 30 days |
Logs and monitoring
| Preset | What it shows | Shown as | Time range |
|---|---|---|---|
| Alarms | Every CloudWatch alarm in this region: those in alarm first, then those without enough data, then those that are OK. | Alarm list | The state now |
| Alarm summary | How many CloudWatch alarms in this region are failing, without enough data and OK, in a few words, such as “2 failing, 20 OK”. | Alarm summary | The state now |
| CloudWatch Logs ingestion | Log data sent to CloudWatch Logs each hour, which most of its bill is for. | Graph | Last day; or 12 hours to 30 days |
| GetMetricData calls | GetMetricData calls each hour, which is how CloudWatch bills for widgets like these. | Graph | Last day; or 12 hours to 30 days |
Time ranges
Each preset starts with a time range of its own. Many can show another instead: choose it under Time range in the preview.
| Preset shows | Time ranges offered |
|---|---|
| A graph, or a number with a sparkline | Any from the last hour to the last 30 days, with enough points to draw: graphs of hourly data start at 12 hours, and of billing data, which AWS updates about every 6 hours, at 3 days. |
| A total over the whole time range, such as Lambda errors by function | Any from the last hour to the last 30 days. |
| Bars, a donut, a gauge or a table of the latest value, such as Spend by service | Only its own: another range wouldn't change what it shows. |
| Spend | Also Month to date. Daily spend, a column a day, offers 7 days, 2 weeks, 30 days and month to date. |
| Alarms | None: each alarm's state now. |
- Each time range is a widget of its own. Add a preset over the last 3 hours and again over the last 7 days to see both.
- Longer ranges use longer periods,
SEARCHexpressions included, so no graph fetches more than 300 points for each metric, as on a dashboard. - Spend over a range: Month-to-date spend over the last 7 days, titled “Spend, last 7 days”, shows what you spent in them: how much the month's estimated charges rose after the first estimate in that time, counting from the start of a new month when they went back to zero.
Spend presets
- They need billing metrics. AWS only sends estimated charges to CloudWatch once you turn on Receive CloudWatch billing alerts in the Billing console, and the first data takes a few hours. See Turn on billing metrics. In AWS Organizations, add the management account to see the whole organisation's spend.
- Month to date starts on the 1st of the month where your iPhone is, or at midnight UTC on the 1st if that's later: AWS bills by the month in UTC, so this month's spend never takes in last month's.
- Month-end forecast is what this month will cost if spending carries on as it has so far: the month's estimated charges times the days in the month, divided by the days gone (at least one). CloudWatch works it out with metric math, so it needs nothing more than the other spend presets. It runs high in the first days of a month, when charges billed on the 1st, such as a support plan or upfront fees, count as if they recurred daily, and settles as the month goes on. Spend and forecast graphs both, so you can watch it settle. Metric math has no year, so February counts as 28 days.
- Spend by service lists every service, biggest first, with short names (EC2, RDS, S3), and adds up the ones that don't fit as Other. Its Total is the sum of the services. To chart a fixed top five, or show your whole account's charges as the total, build the spend-by-service dashboard instead.
Alarm presets
- Alarms lists every metric and composite alarm in the region: those in alarm first, then those without enough data, then those that are OK, with the latest change first within each. As many as fit are shown, then +N more. See alarm lists for the icons and headline.
- Alarm summary counts them in each state in as few words as it can, such as “All 22 OK” or “2 failing, 4 insufficient data, 14 OK”, with each state's symbol on medium and large widgets.
- Both read up to 1,000 alarms. Past that, those in
ALARMare the ones kept, and Alarm summary counts those. With no alarms in the region, the widget says so, such as “There are no alarms in eu-west-2.” - To show only some alarms, or alarms from several regions, put them on a dashboard: see Example: production alarms.
When a preset has no data
A preset shows No data for this time range. when CloudWatch has nothing for it. The usual reasons:
- The account doesn't use that service in the preset's region. The preview says which region it looked in: add the preset again and choose another under Region, or change the account's default region (see Accounts).
- For spend, billing metrics aren't turned on yet, or the first data hasn't arrived.
- S3 bucket sizes and S3 object counts are updated once a day, so a new bucket takes a day to appear.
- Many AWS metrics are only published while there's activity, so a quiet service, or one with nothing failing, can show no data.