A cloud performance monitoring checklist is a list of readings you keep for a workload. Each reading has a pass test, an owner and a change to try, and the test is a yes-or-no question you answer with evidence. This one has 20 readings in seven parts, and it includes the AWS performance metrics for compute and data stores. It is written for IT heads, application owners and engineering managers at mid-size companies in India and the GCC. Their application runs on AWS, Azure or both. The guide names no tools and does not rank any product.
Cloud Performance Monitoring Checklist: The Short Answer
The aim of these readings is to keep an application fast, not only up. A reading is useful when it has a target, a pass test and an owner. A number on a dashboard with none of the three is only a number.
Defaults alone do not cover it. AWS PERF02-BP03 and PERF05-BP02 both list using only default metrics as an anti-pattern. PERF05-BP02 adds assuming CPU and memory are enough (Well-Architected Framework practice pages, as of November 2026). The seven parts run from targets and baselines to the review of the readings themselves. In between come what users feel, compute and network, scaling, data stores, and the request path and dependencies.
The grouping, the pass tests and the suggested owners are Signisys practice. They are built from the AWS and Google Cloud pages named below. The pass limits come from your own targets, so none are given here. For the overview of the work, see the use case on improving cloud application performance. To find what is causing a slow application, read cloud performance issues: 6 causes and their signs.
Last reviewed 2026-11-01 by Manish Sharma.
Key Takeaway A reading without a pass test is only a number. Write the test against your own target and baseline before you trust the reading.
How to Use the 20 Readings
Take one critical user journey, such as placing an order, and start with Part 1 to write its target and baseline. Then read the rest against them, and mark each reading pass or open, with its evidence. Add more journeys once the first one is stable. Avoid changes while you record, since a change mid-reading can muddy the baseline.
A baseline is the value of a reading in a normal window and in a busy window. The owners in the tables are suggestions, so adapt them to your team. A failed test goes to the map near the end of this guide.
Record the value, the window and who read it. If any of the three is missing, the reading counts as open.
Record the value and the window with every reading, for example “peak hour, Thursday”. Without the window, next week’s value has nothing to be compared with.
Cloud Performance Monitoring Checklist, Part 1: Targets and Baselines
Nothing else in the list can be read without a target and a baseline, so these three readings come first. AWS PERF05-BP01, Establish key performance indicators asks for documented thresholds and the business impact of missing them. The Google Cloud page on operational readiness and performance using CloudOps asks for service level objectives. Each objective should be specific, measurable, achievable, relevant and time-bound (SMART). Availability targets are outside this guide.
| Reading and what to record | Pass test | Evidence to keep | Suggested owner | If the test fails |
|---|---|---|---|---|
| 1) A written target for each critical journey: the response-time target for the slow end, and the business impact if it is missed. | When each journey has a written threshold and its impact, signed by the application owner, the test passes. | For example, the signed target document. | Application owner | Otherwise, write the target before reading anything else, because every later test compares against it. |
| 2) A baseline for each reading: the value in a normal window and in a busy window, with the date. | If every reading below has a baseline from both windows, the test passes. | The baseline sheet, for example a dated table. | Platform or operations lead | If it fails, read the quiet and busy windows before making any change. |
| 3) A user-side reading next to the system readings, such as page load time or orders completed. | When each journey shows one user-side reading beside CPU and memory, the test passes. | The dashboard, with the user-side reading visible. | Application owner | If one is missing, add it before the next review, since system readings alone can hide what users feel. |
Cloud Performance Monitoring Checklist, Part 2: What Users Feel
These four readings show what a person using the application experiences. The four signals are latency, traffic, errors and saturation. The downtime causes and warning signs post explains them and the habit of alerting on symptoms first. This part turns them into pass tests. A percentile is the response time that a stated share of requests beat, so a slow-end percentile describes the slowest few.
What Users Feel: Readings 4 to 7
| Reading and what to record | Pass test | Evidence to keep | Suggested owner | If the test fails |
|---|---|---|---|---|
| 4) Response time on the slow end, per journey: the slow percentile and the average, in the busy window. | When the slow-end time is at or under the written target in the busy window, the test passes. | A graph of the slow end for the journey. | Application owner | If it fails, read the six causes, then the matching fix. |
| 5) Throughput in the busy window: requests or transactions served each second at the peak. | If throughput meets planned demand while response time stays within target, the test passes. | A throughput graph for the same window. | Application owner | Otherwise, compare load with response time before changing capacity. |
| 6) Error rate per journey: failed requests as a share of all requests. | When the error rate stays within target and does not climb as load climbs, the test passes. | The error graph beside the load graph. | Engineering lead | If it fails, separate slow errors from fast ones, because they can point to different causes. |
| 7) The reading taken from where users are: response time from a location near them, not only near the workload. | If it is within target and the gap from the in-region reading is known, the test passes. | For example, readings from two places, labelled. | Platform lead | If the gap is large, check distance and path, then consider moving content or data closer. |
Read the Slow End Too
An average can look fine while a share of users waits. Recording the slow percentile beside the average is Signisys practice, and it is why row 4 asks for both. Row 7 follows AWS PERF04-BP07, which lists testing network performance only from a location close to the workload as an anti-pattern.
Cloud Performance Monitoring Checklist, Part 3: Compute and Network
These are the resource readings. They show whether the machines and the network that carry the application have room to spare. Headroom is the gap between current use and the limit. Defaults alone are not enough here either. Each row therefore asks for a ceiling that the team has chosen (Signisys practice).
AWS Performance Metrics for Compute and Data Stores
The AWS performance metrics for compute include CPU utilization, memory utilization, disk I/O and network inbound and outbound. PERF02-BP03, Collect compute-related metrics lists them. For a data store, PERF03-BP03 adds data-store metrics. They might include transactions per second, top queries, average query rates, response times, index usage, table locks, query timeouts and the number of open connections. Google Cloud also gives CPU utilization, memory usage, network traffic, disk I/O and application response times as examples (as of November 2026), and these overlap with the AWS performance metrics above. Read the host behind a data store with the AWS performance metrics in rows 8 to 11 as well.
Compute and Network Readings 8 to 11
| Reading and what to record | Pass test | Evidence to keep | Suggested owner | If the test fails |
|---|---|---|---|---|
| 8) CPU utilisation in the busy window: the peak, and how close it comes to the limit. | When the peak stays under the ceiling you wrote down and response time holds at that peak, the test passes. | A CPU graph with the ceiling drawn on it. | Platform lead | If it fails, size and scale the compute, or cut the work it does. |
| 9) Memory use and pressure over the busy window. | If use stays under the ceiling and shows no steady climb that fails to level off, the test passes. | A memory graph for the window. | Platform lead | Otherwise, find what holds the memory, then size it or fix the code. |
| 10) Disk I/O on the busiest volume: read and write operations and how long they take. | When both stay within the baseline for the same window and the journey meets its target, the test passes. | For example, the disk graph with the baseline value marked. | Platform lead | If it fails, check which job drives the load, then move the hot data or change the volume type. |
| 11) Network latency and loss on the main paths, with network in and out. | If latency and loss stay at the baseline in the busy window, the test passes. | A network graph with the baseline marked. | Platform or network lead | If the path has changed, check the location of the parts, because distance can add delay. |
Cloud Performance Monitoring Checklist, Part 4: Scaling Readings
Two readings cover how quickly the application gains capacity when demand rises. Google Cloud describes autoscaling as reading metrics such as CPU utilisation, memory pressure and queue depth. It then scales out at peak and back in when use is low. Queue depth is the number of items waiting for work. Quotas, load tests, alert design, drills and runbooks are covered in the high availability checklist, so they are not repeated here.
| Reading and what to record | Pass test | Evidence to keep | Suggested owner | If the test fails |
|---|---|---|---|---|
| 12) How fast new capacity arrives: the time between demand rising and new capacity serving requests. | When the journey stays within target while capacity is being added, the test passes. | Scaling events laid over the response-time graph. | Platform lead | If it fails, change the scaling trigger or start capacity sooner. |
| 13) Queue depth for queued work: the number of items that wait, and how long they wait. | If the queue empties inside the target after a busy spell, the test passes. | A queue graph beside the target. | Engineering lead | Otherwise, scale on queue depth instead of CPU, or reduce the work per item. |
Cloud Performance Monitoring Checklist, Part 5: Data Store Readings
In the AWS Performance Efficiency pillar, PERF03-BP03 asks for the host metrics and the data-store metrics together. Reading both can help tell a slow query from a busy host. These AWS performance metrics are listed for data stores in general, not one product. The three readings below are the standing ones.
| Reading and what to record | Pass test | Evidence to keep | Suggested owner | If the test fails |
|---|---|---|---|---|
| 14) Query response time and top queries: the slowest queries and the top queries by load. | When no top query exceeds its share of the journey’s target and the list matches the baseline, the test passes. | The top-queries list with timings. | Database owner | If it fails, change the data work, for example a query, an index or a data layout. |
| 15) Connections, locks and timeouts: open connections, table locks and query timeouts. | If connections stay below the store’s limit with room to spare and locks and timeouts match the baseline, the test passes. | A connection graph with the limit marked. | Database owner | Otherwise, change how the application opens connections or holds locks. |
| 16) Cache hit rate: the share of reads the cache answers. | When the hit rate holds at its baseline, and a fall is looked at, the test passes. | A hit-rate graph over the window. | Database owner or engineering lead | If it falls, the cache may be too small or the data may not suit caching. |
Cloud Performance Monitoring Checklist, Part 6: The Request Path and Its Dependencies
A request crosses the device, the network, the application, its dependencies and the data stores, so the time needs reading at each hop. A dependency is any internal or third-party service the application calls. In this guide, a trace records the path of one request through those hops. Google Cloud says logs show events and errors, and traces show how a request flows. It adds that metrics such as the round-trip time between services can help find bottlenecks. AWS PERF05-BP02 adds end-to-end tracing for traffic patterns and latency. The use case page on tracing a request end to end goes further than this list.
| Reading and what to record | Pass test | Evidence to keep | Suggested owner | If the test fails |
|---|---|---|---|---|
| 17) Time split across the hops of one slow request: the share of the request’s time at each hop, from a trace. | When one trace per journey shows where the time goes and no hop exceeds its share of the target, the test passes. | A trace saved for the journey. | Engineering lead | If it fails, chase the hop with the largest share first. |
| 18) Each dependency’s response time and error rate: how long each call takes and the share of calls that fail. | If each dependency stays within the share of the target you gave it and its errors match the baseline, the test passes. | A per-dependency graph. | Engineering lead | Otherwise, set timeouts, cache what can be cached and take the timings to the dependency’s owner. |
Cloud Performance Monitoring Checklist, Part 7: Keeping the Readings Useful
Readings can go stale as the application changes. In the AWS Performance Efficiency pillar, PERF05-BP07 asks for a review on a set cadence. It also asks for a baseline and a desirable value for each metric, and a look at which metrics helped in the last incident. It also lists letting metrics stay in an alarm state for an extended period as an anti-pattern. The cadence is yours to choose.
| Reading and what to record | Pass test | Evidence to keep | Suggested owner | If the test fails |
|---|---|---|---|---|
| 19) A review of the readings on a set cadence, with dated notes of each review. | When the last review is dated, no alarm has sat in the alarm state unreviewed and thresholds were checked against the baseline, the test passes. | The review notes. | Operations lead | If it fails, book the review, then clear or retune the alarms. |
| 20) Gaps found after the last incident: which readings helped and which were missing. | If each missing reading is added or has a written reason for being left out, the test passes. | For example, the list from the last incident review. | Operations lead | Otherwise, add the reading and its pass test to this checklist. |
What to Do When a Reading Fails
Take the failed reading to its cause, then to the fix, then read it again against the same baseline. The cause is in the guide to cloud performance issues linked in the short answer. The order of fixes is in the guide to cloud performance optimization. This fix map is Signisys practice, not a standard.
- Slow-end time or throughput (rows 4, 5, 12): capacity, data work, distance, a dependency, a platform limit or the design.
- Error rate (row 6): separate slow errors from fast ones, then follow the matching cause.
- CPU, memory, disk (rows 8 to 10): size and scale, or cut the work.
- Network and user location (rows 7, 11): distance and path.
- Data store (rows 14 to 16): the data work or the cache.
- Dependency (rows 17, 18): timeouts, caching and the dependency’s owner.
- A reading with no baseline: write one first.
Try One Change at a Time
As an illustration with no numbers: the order screen is slow at the busy hour, row 4 fails, row 8 passes and row 14 fails. The data work is the first change to try. Change one thing at a time. Then read the same readings in the same window, so you can tell which change helped.
Key Takeaway Change one thing at a time, then read the same readings in the same window against the same baseline.
Signisys provides cloud services and platform engineering, including help with improving cloud application performance. The conversation is about reading your results and choosing the next change, and the readings stay with your own team. The cloud architecture, reliability and resilience page explains the wider approach, and the cloud computing service page lists what Signisys offers.
What This Checklist Does Not Cover
This list covers speed readings for one application. It leaves out the cause, the order of fixes, choosing software, cost, security, backup, downtime and recovery, and rules that apply by sector or country in India and the GCC. A performance checklist for cloud workloads is also not a substitute for load testing before a launch. The readings use only the AWS performance metrics for compute and data stores, so metrics for other services are left out. To choose software for these readings, see the guide on comparing provider-native and third-party tools.
Get specialist help when readings point in more than one direction, when slowness only shows under real load, or when a design change touches live data.
Cloud Performance Monitoring Checklist FAQ
What should a cloud performance monitoring checklist include?
How do you set a pass test when you have no baseline yet?
Why read the slow end of response time and not only the average?
Which reading should you check first when users say the application is slow?
Who should own each reading?
Is performance monitoring the same as observability?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.