Create a Simple Alarm, Inspect a Log Group, and Read One Failure Signal
Hands-on lab: trigger Lambda success and failure, inspect CloudWatch metrics and logs, create your first alarm, and learn the troubleshooting order.
All services used in this lesson are covered by the AWS Free Tier.
AWS Services Used
What you are building
Lambda is the easiest place to start with monitoring because it automatically publishes invocation metrics to CloudWatch, and its logs go into CloudWatch Logs. You can see both a metric signal and log output without setting up a CloudWatch agent on a server.
What you will do
- Use a simple Lambda function
- Trigger one success and one failure
- Inspect the log group and log stream
- Create an alarm on the Lambda Errors metric
Lab setup
Use any test Lambda function you already have. If you do not have one yet, create a very small test function in the Lambda console and invoke it manually. Lambda automatically tracks requests, duration, and errors in CloudWatch.
A simple pattern is:
- First run a successful invocation
- Then intentionally trigger one failure
- Then inspect metrics and logs
Part 1: Trigger one success and one failure
Invoke your Lambda function once successfully. Then trigger a failure in a safe way, such as returning or throwing an error on purpose in a test path. Lambda records request counts, duration, and errors automatically.
Note
The metric timestamp reflects when the function was invoked, and depending on execution length, metrics can appear a bit later than you expect. For long-running functions, you may need to look farther back in time to see the correct metric timestamp.
Part 2: Inspect the metrics
Open CloudWatch and look at the Lambda metrics for your function. The easiest first signals are:
- Invocations
- Errors
- Duration
What you are looking for
- Did Invocations increase?
- Did Errors go above zero after the failure?
- Did Duration change in a surprising way?
Part 3: Inspect the logs
Open CloudWatch Logs and find the log group for your Lambda function. Log events live inside log streams, and log streams live inside a log group.
Look for:
- The most recent log stream
- A line showing the error
- Any request or execution context that helps explain the failure
Note
By default, CloudWatch Logs stores log data indefinitely unless you set a retention policy on the log group.
Part 4: Create the alarm
In the CloudWatch console:
- Go to Alarms
- Choose Create alarm
- Choose Select metric
- Select the Lambda Errors metric for your function
- Set a simple threshold such as "Errors >= 1" for one evaluation period
- Save the alarm
Tip
A newly created alarm can begin in the INSUFFICIENT_DATA state before CloudWatch evaluates it and sets the proper state. This is normal.
Part 5: Read the signal correctly
This is the workflow:
- Metric: I see an error count
- Log: I read the exact failure line
- Alarm: I turn this into a repeatable warning rule
That order matters because metrics tell you that something changed, logs tell you why, and alarms help you stop missing it next time.
Verify your work
| Step | Success condition |
|---|---|
| Trigger a successful Lambda run | Invocations increased |
| Trigger a failed Lambda run | Errors increased |
| Open CloudWatch Logs | You found the right log group |
| Open the newest log stream | You found the latest events |
| Create an alarm on Errors | Alarm exists in CloudWatch |
| Explain the result | You can say what metric changed and what log line explained it |
Micro-activity 1: Reflection
Think about it
After the lab, reflect: Which metric changed after the failure? What was the alarm threshold? What log group did you inspect? What line or message best explained the error? Did the alarm begin in OK, ALARM, or INSUFFICIENT_DATA?
Micro-activity 2: Troubleshooting drill
A learner says: "My function failed, but I only looked at the alarm."
Think about it
Write a better 3-step response: (1) Check the ___, (2) Read the ___, (3) Then use the ___ as the repeatable warning layer. Remember the order: metrics first, logs second, alarms third.
Summary
CloudWatch alarms watch metrics, log groups contain log streams, and Lambda automatically publishes core invocation metrics to CloudWatch. That makes Lambda one of the best services for a first monitoring lab.
The most important habit is not the button-clicking. It is learning the order: metrics first, logs second, alarms third. Metrics tell you that behavior changed, logs show the event details, and alarms help you react faster the next time.