How to Monitor AWS DynamoDB with Vigilmon

AWS DynamoDB is Amazon's fully managed NoSQL database — fast, scalable, and deeply integrated into the AWS ecosystem. It powers everything from serverless APIs to gaming leaderboards to e-commerce carts. But "managed" doesn't mean you can ignore monitoring. DynamoDB tables can hit throughput limits, experience increased latency, or become temporarily unavailable during regional disruptions.

This guide explains how to monitor your DynamoDB-dependent applications with Vigilmon using an application-layer approach.

Why DynamoDB Monitoring Matters

DynamoDB is designed for high availability, but your application's dependency on it creates failure points:

• Provisioned throughput exceeded: Read or write capacity units exhausted, causing throttling
• Hot partition keys: Uneven data access patterns causing individual partitions to throttle
• Regional service disruptions: Rare but real AWS regional events
• Code or schema issues: Application-level bugs that cause 400 errors or unexpected data

The challenge: DynamoDB is inside your AWS VPC. You can't directly monitor it from the outside. The right approach is to expose a health check in your application that performs a lightweight DynamoDB operation.

Setting Up DynamoDB Monitoring with Vigilmon

Step 1: Add a DynamoDB Health Check Endpoint

Add a lightweight health check to your API that verifies DynamoDB connectivity:

Node.js / Express with AWS SDK v3:

import { DynamoDBClient, DescribeTableCommand } from '@aws-sdk/client-dynamodb';

const dynamo = new DynamoDBClient({ region: process.env.AWS_REGION });

app.get('/health/dynamo', async (req, res) => {
  try {
    const start = Date.now();
    await dynamo.send(new DescribeTableCommand({
      TableName: process.env.DYNAMO_TABLE_NAME
    }));
    const latency = Date.now() - start;

    res.status(200).json({
      status: 'healthy',
      latency_ms: latency,
      table: process.env.DYNAMO_TABLE_NAME
    });
  } catch (error) {
    res.status(503).json({
      status: 'unhealthy',
      error: error.message
    });
  }
});

Python / Lambda example:

import boto3
import json
import time

dynamodb = boto3.client('dynamodb', region_name='us-east-1')

def health_handler(event, context):
    try:
        start = time.time()
        dynamodb.describe_table(TableName=os.environ['TABLE_NAME'])
        latency = (time.time() - start) * 1000

        return {
            'statusCode': 200,
            'body': json.dumps({'status': 'healthy', 'latency_ms': latency})
        }
    except Exception as e:
        return {
            'statusCode': 503,
            'body': json.dumps({'status': 'unhealthy', 'error': str(e)})
        }

DescribeTable is a lightweight metadata call that doesn't consume read capacity units, making it ideal for health checks.

Step 2: Sign Up for Vigilmon

Visit vigilmon.online. The free tier includes 10 monitors with 3-minute check intervals — no credit card required.

Step 3: Add an HTTP Monitor

1. Click Add Monitor in the Vigilmon dashboard
2. Select HTTP monitor type
3. Enter your health URL (e.g., https://api.yourapp.com/health/dynamo)
4. Set expected status code: 200
5. Enable multi-region checks (US, EU, AP) — important for detecting AWS regional issues
6. Configure your check interval

Step 4: Add Monitors for Critical Application Paths

Beyond the DynamoDB health check, add monitors for the API endpoints that are most DynamoDB-dependent:

• Your primary API endpoint (e.g., https://api.yourapp.com/health)
• Any critical user-facing endpoints if they return predictable responses

Step 5: Configure Alerts

Set up notifications via:

• Email: Immediate alert to your team
• Slack: Post to #incidents with context about which service failed
• PagerDuty: For on-call rotation during high-severity incidents
• Webhooks: Trigger Lambda functions to auto-scale DynamoDB capacity or create AWS support cases

Key Signals to Track

Signal	Likely Cause
Health check returns 503	DynamoDB connectivity lost, auth failure, or table deleted
Health check response time spikes	DynamoDB throttling, hot partition, or cross-region latency
Intermittent failures	Provisioned capacity limits being hit sporadically
Multiple regions failing	AWS regional incident

Alert Configuration Tips

Multi-region confirmation before alerting: Vigilmon can require failures from 2+ regions before firing an alert. This prevents false alarms from transient single-region network issues while still catching real DynamoDB outages quickly.

Escalate DynamoDB alerts faster: DynamoDB failures tend to be high-impact (often full application outages). Consider a shorter confirmation window and PagerDuty escalation for DynamoDB monitors specifically.

Separate monitors per table or service: In microservices architectures where different services own different DynamoDB tables, add a dedicated health check per service. This isolates which table is having issues during incidents.

Pairing Vigilmon with CloudWatch

AWS CloudWatch provides DynamoDB metrics like:

• ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits
• SystemErrors and UserErrors
• SuccessfulRequestLatency

Vigilmon complements CloudWatch by providing the external, user-facing view. CloudWatch tells you how DynamoDB is performing internally; Vigilmon tells you whether your application is actually serving requests successfully.

Heartbeat Monitoring for DynamoDB Streams Consumers

If you use DynamoDB Streams with Lambda consumers for change data capture or event-driven workflows, use Vigilmon's heartbeat monitor to verify your consumers are processing events. Configure your Lambda to ping a Vigilmon heartbeat URL after each successful batch; if pings stop, you're immediately alerted to a stalled consumer.

Get Started

DynamoDB reliability is critical for modern serverless applications. Set up external monitoring at vigilmon.online — it's free to start, no credit card needed.

With Vigilmon's free tier covering 10 monitors and paid plans starting at $6/month, you can monitor your DynamoDB integration alongside every other critical service in your stack.