Aurora MySQL stored procedure errors not appearing in Cloudwatch error logs?

In addition to the answer of the re:Post Agent:

Technical Addendum: Professional Error Handling in Aurora MySQL

The other answer is correct regarding the technical limitations of standard Error Logs. However, for a production-grade partition maintenance setup, the following two points are critical to bridge the gap between "it doesn't work" and a reliable alerting system:

1. The "Silent Failure" of the Event Scheduler

Partition maintenance is typically executed via the MySQL Event Scheduler.

• Unlike a manual query in MySQL Workbench, background events have no "client" to receive an error message. If the procedure fails, it fails silently unless you have explicitly defined an internal error handler.
• Recommendation: You must implement a DECLARE EXIT HANDLER FOR SQLEXCEPTION within your stored procedure to catch errors that would otherwise be lost.

2. Native Lambda Integration vs. Polling

The agent's "fallback" (Table + Lambda Polling) is a legacy approach that introduces latency and unnecessary costs for empty table scans.

• more modern approach: Use Aurora Native Lambda Integration. Instead of writing to a table and waiting for a poller, your stored procedure can trigger an AWS Lambda function immediately when an error occurs.
• advantage: Real-time alerting and zero overhead when the procedure runs successfully.

Prerequisites for this approach:

• IAM Role: The Aurora Cluster needs an IAM role with lambda:InvokeFunction permissions.
• Cluster Parameter Group: Ensure aws_default_lambda_role is set to the ARN of that IAM role.
• VPC Security: The Aurora cluster must have outbound connectivity (via NAT Gateway or Lambda VPC Endpoint) to reach the Lambda service.

If you are concerned about the error being lost if the Lambda call itself fails, you can use a nested BEGIN...END block with its own CONTINUE HANDLER. This ensures that even if the alert trigger encounters an issue, your procedure can still complete its logging or cleanup logic gracefully... but that might be overkill .

Based on how Aurora MySQL error logging works, stored procedure errors and SQL failures executed by client applications are typically not written to the Aurora MySQL error logs, which is why they're not appearing in CloudWatch Logs.

Understanding Aurora MySQL Error Log Behavior:

Aurora MySQL writes to the error log only during specific conditions: startup, shutdown, and when the database engine itself encounters errors. The error log is designed to capture unexpected system-level events and database engine errors, not application-level errors or query failures from client sessions. A DB instance can go hours or days without new entries if no system-level errors occur.

Answers to Your Specific Questions:

1. Stored procedure errors from client executions are generally NOT captured in CloudWatch error logs because they don't meet the criteria for being written to the Aurora error log. These are considered application-level errors rather than database engine errors.

2. Conditions for error logging: Errors are written to Aurora error logs primarily for database engine-level issues - startup problems, shutdown issues, and internal database errors. Client-side query failures, including stored procedure errors triggered via SIGNAL SQLSTATE, are returned to the client but typically not logged to the error log.

3. Configuration options: While you can enable general logs or slow query logs to capture SQL statement execution, these logs are designed for different purposes (capturing all queries or slow queries respectively) and would generate significant overhead. They're not specifically designed for error capture from stored procedures.

Recommendation:

Your proposed fallback solution using a custom error logging table with Lambda polling is actually the recommended approach for this use case. This pattern gives you:

• Explicit control over what errors to capture
• Ability to add custom metadata and context
• More reliable alerting for application-level errors
• Lower overhead than enabling general logging

CloudWatch-based alerting for stored procedure errors is not feasible with the standard Aurora MySQL error logs, as these logs don't capture application-level SQL errors from client sessions.
Sources
Overview of Aurora MySQL database logs - Amazon Aurora
Logging for Aurora MySQL databases - Amazon Aurora