docs/sources/datasources/aws-cloudwatch/troubleshooting/index.md
This document provides solutions to common issues you may encounter when configuring or using the Amazon CloudWatch data source. For configuration instructions, refer to Configure CloudWatch.
{{< admonition type="note" >}} The data source health check validates both metrics and logs permissions. If your IAM policy only grants access to one of these (for example, metrics-only or logs-only), the health check displays a red status. However, the service you have permissions for is still usable—you can query metrics or logs based on whichever permissions are configured. {{< /admonition >}}
These errors occur when AWS credentials are invalid, missing, or don't have the required permissions.
Symptoms:
Possible causes and solutions:
| Cause | Solution |
|---|---|
| IAM policy missing required permissions | Attach the appropriate IAM policy to your user or role. For metrics, you need cloudwatch:ListMetrics, cloudwatch:GetMetricData, and related permissions. For logs, you need logs:DescribeLogGroups, logs:StartQuery, logs:GetQueryResults, and related permissions. Refer to Configure CloudWatch for complete policy examples. |
| Incorrect access key or secret key | Verify the credentials in the AWS Console under IAM > Users > your user > Security credentials. Generate new credentials if necessary. |
| Credentials have expired | For temporary credentials, generate new ones. For access keys, verify they haven't been deactivated or deleted. |
| Wrong AWS region | Verify the default region in the data source configuration matches where your resources are located. |
| Assume Role ARN is incorrect | Verify the role ARN format: arn:aws:iam::<account-id>:role/<role-name>. Check that the role exists in the AWS Console. |
Symptoms:
Solutions:
sts:AssumeRole permission.Example trust policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<your-account-id>:user/<grafana-user>"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "<your-external-id>"
}
}
}
]
}
Symptoms:
Solutions:
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)~/.aws/credentials)Symptoms:
Solutions:
~/.aws/credentials for the user running the grafana-server service.0644)./usr/share/grafana/ and set permissions to 0644.These errors occur when Grafana cannot reach AWS CloudWatch endpoints.
Symptoms:
Solutions:
Symptoms:
Solutions:
These errors occur when querying CloudWatch Metrics.
Symptoms:
Possible causes and solutions:
| Cause | Solution |
|---|---|
| Time range doesn't contain data | Expand the dashboard time range. CloudWatch metrics have different retention periods based on resolution. |
| Wrong namespace or metric name | Verify the namespace (for example, AWS/EC2) and metric name (for example, CPUUtilization) are correct. |
| Incorrect dimensions | Ensure dimension names and values match your AWS resources exactly. |
| Match Exact enabled incorrectly | When Match Exact is enabled, all dimensions must be specified. Try disabling it to see if metrics appear. |
| Period too large | Reduce the period setting or set it to "auto" to ensure data points are returned for your time range. |
| Custom metrics not configured | Add custom metric namespaces in the data source configuration under Namespaces of Custom Metrics. |
Symptoms:
Solutions:
cloudwatch:ListMetrics permission.ListMetrics to 500 results per page. To retrieve more metrics, increase the list_metrics_page_limit setting in the Grafana configuration file.Symptoms:
Solutions:
cloudwatch:ListMetrics permission.ec2:DescribeTags and ec2:DescribeInstances permissions are granted.Symptoms:
Solutions:
GetMetricData requests per second in the AWS Service Quotas console.Symptoms:
Solutions:
These errors occur when querying CloudWatch Logs.
Symptoms:
Solutions:
logs:StartQuery, logs:GetQueryResults, and logs:DescribeLogGroups permissions.Symptoms:
Solutions:
Symptoms:
Solutions:
logs:DescribeLogGroups permission.oam:ListSinks and oam:ListAttachedLinks.Symptoms:
Solutions:
Specify the log group identifier or ARN in the FROM clause:
SELECT * FROM `log_group_name` WHERE `@message` LIKE '%error%'
For multiple log groups, use the logGroups function:
SELECT * FROM `logGroups(logGroupIdentifier: ['LogGroup1', 'LogGroup2'])`
Amazon CloudWatch supports only a subset of OpenSearch SQL commands. Refer to the CloudWatch Logs documentation for supported syntax.
These errors occur when using template variables with the CloudWatch data source.
Symptoms:
Solutions:
cloudwatch:ListMetrics.cloudwatch:ListMetrics.ec2:DescribeInstances.ec2:DescribeVolumes.tag:GetResources.logs:DescribeLogGroups.For more information on template variables, refer to CloudWatch template variables.
Symptoms:
Solutions:
*) wildcard instead of selecting "All" to query all metrics for a dimension.These errors occur when using CloudWatch cross-account observability features.
Symptoms:
Solutions:
Verify cross-account observability is configured in the AWS CloudWatch console.
Add the required IAM permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": ["oam:ListSinks", "oam:ListAttachedLinks"],
"Effect": "Allow",
"Resource": "*"
}
]
}
Check that the monitoring account and source accounts are properly linked in AWS.
Cross-account observability works within a single region—verify all accounts are in the same region.
EC2 Instance Attributes can't be queried across accounts because they use the EC2 API, not the CloudWatch API.
These issues relate to AWS service quotas and cost management.
Symptoms:
Solutions:
GetMetricData requests.Symptoms:
Solutions:
GetMetricData API doesn't qualify for the CloudWatch API free tier.These issues don't produce specific error messages but are commonly encountered.
Symptoms:
Solutions:
CWAgent,CustomNamespace).Symptoms:
Solutions:
Symptoms:
@xrayTraceId field not appearingSolutions:
@xrayTraceId field.@xrayTraceId in the fields, for example: fields @message, @xrayTraceId.To capture detailed error information for troubleshooting:
Set the Grafana log level to debug in the configuration file:
[log]
level = debug
Review logs in /var/log/grafana/grafana.log (or your configured log location).
Look for CloudWatch-specific entries that include request and response details.
Reset the log level to info after troubleshooting to avoid excessive log volume.
If you've tried the solutions above and still encounter issues: