Amazon CloudWatch

Name: Amazon CloudWatch API
Brand: Amazon CloudWatch
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring Observabilityhmac76 EndpointsREST

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.

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.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic 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

GET STARTED

Start building with Amazon CloudWatch API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for Amazon CloudWatch, keeping it validated and agent-ready.

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.

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

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

AWS access keys are stored encrypted in the Jentic MAXsystem vault. Jentic signs each CloudWatch request with SigV4 on the agent's behalf — the agent only ever holds a session, never the raw IAM key.

Intent-based discovery

Agents search by intent (e.g., 'create a CloudWatch alarm on Lambda errors') and Jentic returns the matching CloudWatch operation with its input schema, so the agent can call PutMetricAlarm, PutMetricData or GetMetricData without consulting AWS docs.

Time to first call

Direct CloudWatch integration: 2-4 days for IAM scoping, retry/backoff handling, alarm action wiring and dashboard JSON shaping. Through Jentic: under a day — search, load schemas, chain operations.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

Amazon CloudWatch Logs

CloudWatch Logs ingests log data that backs metric filters and Contributor Insights rules in CloudWatch

Use alongside CloudWatch when an agent needs to extract metrics from log lines or query logs around an alarm event.

Complementary

Amazon EventBridge

EventBridge routes CloudWatch alarm state changes to Lambda, Step Functions and other targets for remediation

Use to drive automation off alarm state changes — e.g., trigger a Lambda to roll back a deploy when a composite alarm transitions to ALARM.

Complementary

AWS X-Ray

X-Ray adds distributed tracing alongside CloudWatch's metrics and alarms

Use when an agent needs request-level latency breakdowns rather than aggregate metrics — pair X-Ray traces with CloudWatch alarms for end-to-end observability.

Alternative

Amazon CloudWatch Application Insights

Application Insights auto-discovers metrics and alarms for common workloads

Choose Application Insights when an agent wants opinionated, auto-configured monitoring for a workload (e.g., a .NET app on EC2). Use raw CloudWatch when bespoke metrics, dashboards and alarms are needed.

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 at https://app.jentic.com/sign-up.

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 the MAXsystem vault 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.