Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

Azure CosmosDB Request Units Rate Limiting 429 Sentinel

Audits Azure Cosmos DB containers via Azure Monitor to detect HTTP 429 throttling and Normalized RU consumption surges, alerting DBAs via Slack.

Categories
CloudInfrastructure

Global enterprise applications and real-time distributed platforms leverage Azure Cosmos DB for multi-model, globally distributed NoSQL database storage with turnkey multi-region replication. Throughput in Cosmos DB is provisioned and metered in Request Units per second (RU/s). When client query volume spikes, batch ETL jobs execute unindexed partition scans, or data skew concentrates writes onto a single hot logical partition key, container throughput demand exceeds the provisioned or autoscale ceiling. When this occurs, Cosmos DB throttles client requests with HTTP 429 Request rate is large status codes. Although client SDKs perform internal exponential backoff retries, persistent throttling inflates client response latencies and eventually results in dropped user transactions. This sentinel interrogates Azure Monitor Metrics every 10 minutes, detects HTTP 429 throttling surges and Normalized RU consumption breaches above 85%, and notifies DBAs on Slack before application outages occur.

How it works

  1. Scheduled triggering: Executes every 10 minutes via automated cron trigger (*/10 * * * *) or runs on-demand via manual execution.
  2. Metric query construction: Interrogates the Azure Monitor Management Client targeting the Cosmos DB database account resource URI.
  3. Telemetry evaluation: Analyzes NormalizedRUConsumption and TotalRequests across a 15-minute rolling lookback window.
  4. Threshold comparison: Verifies whether throttled HTTP 429 request counts exceed max_429_count_threshold or if normalized RU utilization crosses 90%.
  5. Conditional alerting: An io.kestra.plugin.core.flow.If flowable checks if rate limiting occurred and dispatches a Slack alert to #azure-database-alerts.
  6. Manifest export: Emits a structured JSON audit payload detailing consumption metrics and partition scaling advice for database administrators.

Architecture diagram

flowchart TD
  A[ten_minute_cosmosdb_audit Schedule Trigger] --> B[scan_cosmosdb_metrics Python Script]
  B --> C[check_rate_limiting Flowable If]
  C -- RU Throttling Detected --> D[notify_slack_cosmos_throttling Webhook]
  C -- Throughput Nominal --> E[log_database_health_state Log]
  D --> E
  E --> F[export_cosmos_manifest Return]

What you get

  • Proactive detection of Cosmos DB HTTP 429 throttling before client applications crash on transaction timeouts.
  • Visibility into Normalized RU consumption to distinguish hot partition key skew from general cluster saturation.
  • Actionable Slack notifications containing exact RU consumption percentages and autoscale adjustment advice.
  • Structured JSON manifests supporting database performance scorecards and capacity forecasting.

Who it's for

  • Database Administrators (DBAs) managing Azure Cosmos DB SQL API and MongoDB API clusters.
  • Site Reliability Engineers troubleshooting microservice write timeouts and database retry storms.
  • Backend Software Engineers designing partition key schemas and query indexing strategies.

Why orchestrate this with Kestra

Azure Monitor captures metric telemetry, but correlating database rate limiting with operational ChatOps incident response requires automated workflow coordination. Kestra queries Azure Monitor APIs securely via service principal credentials, validates custom capacity thresholds, formats actionable alert cards, and can trigger automated throughput scaling. With Kestra's containerized Python runner and native secret management, teams maintain reliable database guardrails without deploying brittle monitoring agents.

Use cases

  • Hot Partition Key Skew Identification: Detect when an uneven partition key strategy directs excessive write volume to a single physical partition.
  • Autoscale Throughput Ceiling Warning: Alert DBAs when transactional demand reaches the configured max autoscale RU/s limit.
  • Batch Data Load Throttling Prevention: Monitor database health during large nightly data migration runs to prevent throttling of daytime online traffic.

Inputs

Name Type Default Description
azure_subscription_id STRING 12345678-1234-1234-1234-123456789abc Azure subscription identifier containing the Cosmos DB account.
resource_group_name STRING rg-production-databases Name of the Azure Resource Group hosting the Cosmos DB account.
cosmosdb_account_name STRING cosmos-ecommerce-orders Target Azure Cosmos DB account identifier to evaluate for RU rate limiting.
max_429_count_threshold INT 10 Maximum allowable HTTP 429 rate-limited request count across the lookback window.
alert_on_throttling BOOL true Whether to dispatch automated Slack alerts when Cosmos DB Request Units are throttled.

Expected outputs

  • {{ outputs.scan_cosmosdb_metrics.vars.account_name }}: Identifier of the evaluated Cosmos DB account.
  • {{ outputs.scan_cosmosdb_metrics.vars.normalized_ru_percent }}: Maximum recorded Normalized RU consumption percentage.
  • {{ outputs.scan_cosmosdb_metrics.vars.is_throttled }}: Boolean flag indicating whether rate limiting or RU saturation was detected.
  • {{ outputs.export_cosmos_manifest.value }}: Structured dictionary containing the consolidated Cosmos DB diagnostic manifest.

Prerequisites

  • Outbound HTTPS network access from Kestra execution workers to Azure Resource Manager endpoints (management.azure.com).
  • An Azure Service Principal configured with Monitoring Reader permissions on the target resource group.
  • A Slack Incoming Webhook URL configured in Kestra secrets.

Secrets

  • AZURE_CLIENT_ID: Service Principal Application (Client) ID.
  • AZURE_CLIENT_SECRET: Service Principal Secret.
  • AZURE_TENANT_ID: Azure Active Directory Directory (Tenant) ID.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch database incident notifications.

Quick start

  1. Register AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, and SLACK_WEBHOOK_URL in your Kestra secret storage.
  2. Import this blueprint into your Kestra instance under the company.cloud namespace.
  3. Update azure_subscription_id, resource_group_name, and cosmosdb_account_name with your Cosmos DB deployment details.
  4. Run a manual execution to test Azure Monitor authentication and verify the structured output manifest.

Common pitfalls and troubleshooting

  • Normalized RU Metric: NormalizedRUConsumption represents the maximum throughput utilization across any single partition; this catches hot partition bottlenecks even if total account RU is low.
  • Metric Latency: Azure Monitor metrics have an ingestion latency of 1 to 3 minutes; querying a 15-minute rolling window avoids null data series.
  • Service Principal Role: Ensure the service principal has Microsoft.Insights/metrics/read permission on the Cosmos DB account.

How to extend

  • Automated RU Scale-Up: Add a downstream Azure CLI task to automatically bump Cosmos DB autoscale max RU/s when persistent 429s are detected.
  • Partition Key Diagnostic Drill: Dispatch an Azure Cosmos DB diagnostic query to log the top 5 partition keys responsible for the consumption surge.
  • Multi-Account Database Audit: Wrap the evaluation in an io.kestra.plugin.core.flow.ForEach loop to scan all Cosmos DB databases across production subscriptions.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.