AWS Amazon CloudWatch
Browse all Amazonaws APIsAgent-ready OpenAPI document · curated by JenticDeveloper ToolsMonitoring Observabilityhmac76 EndpointsREST
Know of an official OpenAPI document? Contribute it →
For Agents
Push and query time-series metrics, configure metric and composite alarms, manage dashboards, and stream metrics to downstream consumers across an AWS account.
Use for: Publish a custom metric for application throughput to CloudWatch, Query the average CPU utilisation for an instance over the last 24 hours, Create a CloudWatch alarm when error rate exceeds 5 percent, Set up an anomaly detector on the request latency metric
Not supported: Does not handle log ingestion, distributed tracing, or synthetic uptime checks - use for metric publishing, alarms, dashboards, and metric streams only.
Jentic publishes the only available OpenAPI specification for Amazon CloudWatch, keeping it validated and agent-ready. Amazon CloudWatch is AWS's metric, alarm, and dashboard service for cloud and application observability - it ingests time-series metric data, evaluates static and anomaly-detection alarms, runs Contributor Insights rules, manages metric streams to downstream consumers, and stores configurable dashboards. The 76 endpoints cover PutMetricData ingest, GetMetricData and GetMetricStatistics queries, alarm CRUD with composite alarm support, dashboard JSON management and metric stream provisioning to Kinesis Firehose.
Install Jentic One Beta
Connect the Amazon CloudWatch to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Amazon CloudWatch, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Famazonaws.com%2Famazon-cloudwatch" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Famazonaws.com%2Famazon-cloudwatch" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Amazon CloudWatch API.
Publish custom metric data points with dimensions, units, and statistical sets to any namespace
Query historical metric values with GetMetricData using period, statistic, and metric math expressions
Configure metric alarms (static thresholds and anomaly-detection bands) and composite alarms that combine other alarms
Manage CloudWatch dashboards as versioned JSON, including widget layout and per-widget metric queries
Run Contributor Insights rules over CloudWatch Logs to surface top-N contributors against a metric
Stream filtered metrics to Kinesis Firehose destinations for ingestion into data warehouses
Tag CloudWatch resources for cost allocation and apply per-resource IAM policies
Use Cases
Patterns agents use Amazon CloudWatch API for, with concrete tasks.
★ Publish and Query Custom Application Metrics
Engineering teams need a place to ship custom application metrics - request counts, queue depths, business KPIs - and query them for dashboards and alerts. CloudWatch's PutMetricData accepts batched data points with dimensions and statistical sets, and GetMetricData runs metric math expressions across them with up to a one-second resolution. The same data backs alarms and dashboards without needing a separate time-series database.
Call PutMetricData with namespace=MyApp, MetricName=OrdersProcessed, dimensions=[{Name:Service,Value:checkout}], and a value, then query the same metric with GetMetricData over the last hour
Drive Auto-Remediation From Composite Alarms
Production runbooks often need to trigger only when several conditions hold simultaneously - high error rate AND high latency AND a recent deploy. CloudWatch composite alarms combine other alarms with boolean expressions and notify SNS or trigger Systems Manager actions. An agent can wire up the constituent alarms, build the composite expression, and attach actions for paging or rollback.
Call PutMetricAlarm for ErrorRateHigh and LatencyHigh, then PutCompositeAlarm with AlarmRule='ALARM(ErrorRateHigh) AND ALARM(LatencyHigh)' and an SNS topic action
Stream a Filtered Metric Set Into a Data Lake
Organisations centralising telemetry in a data lake need a continuous feed of CloudWatch metrics rather than polling GetMetricData on a schedule. Metric streams push selected namespaces and metric names through Kinesis Firehose to S3, Splunk or third-party observability platforms in OpenTelemetry or JSON formats. An agent can filter by namespace and provision the stream end-to-end without writing collector code.
Call PutMetricStream with a filter for namespace=AWS/Lambda, an OutputFormat of opentelemetry0.7, and a Kinesis Firehose ARN as the destination
AI Agent Integration for Observability Operations
Through Jentic, an SRE-style agent can manage CloudWatch entirely through natural-language intents - query metrics, create alarms, edit dashboards, mute actions during a deploy. Jentic resolves each intent to the right CloudWatch operation and brokers SigV4 credentials, so on-call automation can be built from LLM tool calls rather than bespoke boto3 scripts.
Resolve the intent 'create a CloudWatch alarm on Lambda errors' via Jentic search, load the PutMetricAlarm schema, and execute it with a metric, threshold, period and SNS action
Key Endpoints
76 endpoints — jentic publishes the only available openapi specification for amazon cloudwatch, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
POST
/#Action=PutMetricData
Publish custom metric data points
POST
/#Action=GetMetricData
Query metric data with metric math expressions
POST
/#Action=PutMetricAlarm
Create or update a metric alarm
POST
/#Action=PutCompositeAlarm
Create or update a composite alarm
POST
/#Action=DescribeAlarms
List alarms with filters by state and prefix
POST
/#Action=PutDashboard
Create or update a dashboard JSON definition
POST
/#Action=PutMetricStream
Provision a metric stream to Kinesis Firehose
POST
/#Action=DeleteAlarms
Delete one or more alarms
POST
/#Action=PutMetricData
Publish custom metric data points
POST
/#Action=GetMetricData
Query metric data with metric math expressions
POST
/#Action=PutMetricAlarm
Create or update a metric alarm
POST
/#Action=PutCompositeAlarm
Create or update a composite alarm
POST
/#Action=DescribeAlarms
List alarms with filters by state and prefix
POST
/#Action=PutDashboard
Create or update a dashboard JSON definition
POST
/#Action=PutMetricStream
Provision a metric stream to Kinesis Firehose
POST
/#Action=DeleteAlarms
Delete one or more alarms
Why Jentic?
What agents get from Jentic-routed access to this vendor.
Setup
Wiring Amazon CloudWatch by hand means implementing Signature Version 4 signing, resolving the regional monitoring host, and building the query-style Action parameters yourself. Through Jentic you install once, import CloudWatch from the API Directory, store the AWS keys once, and your agent calls it.
Permission scoping
CloudWatch is an action API where metric names, alarms, and dashboards travel in the request body, so scope the agent to the operations it needs, such as PutMetricData, GetMetricData, and DescribeAlarms. You choose the operations it may call, so ones like alarm deletion are not included unless you add them.
Credential isolation
Your AWS access keys are stored once, encrypted, by your own Jentic One instance and each request is signed with Signature Version 4 at execution time. They never enter the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'create a CloudWatch alarm on Lambda errors' or 'publish a custom metric', and Jentic returns the matching CloudWatch operation with its input schema, so the agent calls PutMetricAlarm or PutMetricData without browsing the reference docs.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Amazon CloudWatch API through Jentic.
Why is there no official OpenAPI spec for Amazon CloudWatch?
AWS does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Amazon CloudWatch via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.
What authentication does the Amazon CloudWatch API use?
CloudWatch is signed with AWS Signature Version 4 using IAM access keys. Permissions are governed by the cloudwatch:* actions, with separate IAM scopes for PutMetricData, alarm management, dashboards and metric streams. Through Jentic, those AWS credentials sit in your Jentic One instance and are used to sign each request on the agent's behalf.
Can I publish high-resolution metrics with the CloudWatch API?
Yes. PutMetricData accepts a StorageResolution of 1 (one second) on individual data points to support high-resolution metrics, alongside the default 60-second resolution. High-resolution metrics are billed at a higher rate and surface in alarms with periods as low as 10 seconds.
What are the rate limits for CloudWatch?
PutMetricData supports up to 1,000 metric data points per request and is throttled per-account per-region; AWS publishes service quotas that can be raised on request. Treat throttling as expected at high cardinality and batch metrics by namespace and dimension before sending.
How do I create a CloudWatch alarm through Jentic?
Use the Jentic search query 'create a CloudWatch alarm', load the PutMetricAlarm schema, and execute it with AlarmName, MetricName, Namespace, Threshold, Period, ComparisonOperator and an SNS topic ARN as the AlarmAction. Jentic signs the request with SigV4 on the agent's behalf.
How does anomaly detection work in CloudWatch?
Call PutAnomalyDetector with a Namespace, MetricName and Stat to build a learned baseline band for that metric, then reference the anomaly detection band in a PutMetricAlarm via the ThresholdMetricId field instead of a static Threshold. The alarm fires when the metric leaves the modelled band.
Can I limit what my agent is allowed to do with the Amazon CloudWatch API?
Yes. Because you run Jentic One yourself, your own rules decide which CloudWatch operations and credentials the agent can use. CloudWatch is an action API where metric names, alarms, and dashboards travel in the request body, so you scope the agent to only the operations it needs, such as PutMetricData, GetMetricData, and DescribeAlarms. Higher-impact operations like alarm deletion are not available to the agent unless you explicitly add them.
GET STARTED