AWS CloudWatch Logs Not Showing Up How to Fix

“`html

Why your logs disappeared — the three common causes

You enabled CloudWatch Logs on your EC2 instance. You waited. You checked the console. Nothing. Just an empty dashboard where data should be flowing in.

As someone who spent three hours debugging this exact problem at 2 AM, I learned everything there is to know about why logs vanish. The issue almost never means CloudWatch itself is broken. It means one of three layers between your application and the console has collapsed — IAM permissions, then agent or application configuration, then log group existence. Break any link in that chain, and logs vanish.

The real pain point? Everything appears “set up” from a quick glance. CloudWatch is enabled. Your EC2 instance exists. But logs aren’t flowing. Probably should have opened with this section, honestly — it would’ve saved me hours of staring at an empty log console wondering if I was losing my mind.

Here’s the mental model I use now: Your application writes logs. The CloudWatch agent or application library tries to send them. But first it checks permissions. Then it reads its configuration file. Then it attempts to push data to a log group that either exists or doesn’t. Each step is a potential failure point, and the order matters because you want to troubleshoot the most common culprits first.

Check IAM role and CloudWatch Logs permissions first

This is the most common reason logs vanish. Your EC2 instance has an IAM role attached — or it doesn’t, and that’s already a problem.

Step one: Find your EC2 instance role. In the AWS console, navigate to EC2 instances, select your instance, and look at the IAM role field under the Details tab. If it’s empty, you need to create and attach a role before anything else will work.

If a role exists, open IAM and find that role. Check the Permissions tab. You’ll need at least these three actions in the policy document:

• logs:CreateLogGroup
• logs:CreateLogStream
• logs:PutLogEvents

Here’s what the minimum policy JSON looks like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

That wildcard at the end covers any log group in any region. You can tighten it later to specific log group ARNs if you want. The point is making sure those three permissions exist — period.

Common mistake I made: I had logs:PutLogEvents but forgot CreateLogStream. Logs couldn’t create a stream within an existing group, so nothing showed up. The agent silently failed. No error messages. Just silence.

After you add or fix the policy, the instance needs to assume the new role. Restarting the CloudWatch agent forces it to re-authenticate. On Linux, that’s sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s. On Windows, restart the AmazonCloudWatch service in Services or your application container.

Verify the CloudWatch Logs agent is running

Assuming IAM is correct, the next failure point is the agent itself. Either it’s not running, or it’s running with the wrong configuration.

On Linux, check if the agent process is active:

ps aux | grep amazon-cloudwatch-agent

You should see a process like /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent. If nothing appears, the agent isn’t running. Start it with:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a query -m ec2 -c default -s

On Windows, open Services (services.msc) and look for “AmazonCloudWatch”. If it’s stopped, right-click and select Start.

But the agent can be running and still not send logs if the config file is wrong. The agent reads from /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json on Linux or C:\ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json on Windows.

Open that file. Look for two critical fields: the log file path your application writes to, and the log group name where you expect logs to appear. I once had a config pointing to /var/log/myapp.log but the application was writing to /var/log/app/output.log. Different paths. Agent watched the wrong file. No logs showed up.

Here’s a minimal config section that works:

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/myapp.log",
            "log_group_name": "my-app-logs",
            "log_stream_name": "instance-{instance_id}"
          }
        ]
      }
    }
  }
}

The key things: file_path must match where your application actually writes. log_group_name is where logs will appear in CloudWatch. And log_stream_name can use the {instance_id} token to auto-populate the instance ID.

After editing the config, restart the agent to pick up changes:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s

Confirm log groups exist and are receiving data

By now, IAM is correct and the agent is running with the right config. The next question: does the log group actually exist? And is data actually flowing into it?

Use the AWS CLI to list all log groups in your region:

aws logs describe-log-groups --query 'logGroups[*].logGroupName'

Look for the log group name you specified in the agent config. If it doesn’t exist, check two things: the agent config has the correct name without typos, and the agent has permission to create it — which it does if IAM is set up right.

If the log group exists but is empty, dig deeper. Check if log streams are being created:

aws logs describe-log-streams --log-group-name my-app-logs

You should see at least one stream with a name matching your config. If streams exist, check if they have recent events:

aws logs tail my-app-logs --follow

This command streams new log entries in real-time. If nothing appears, it means data isn’t being written yet — that might be fine. Your application just hasn’t logged anything. Force it to log something by triggering an action in your app.

If streams exist but show no events even after your app should have logged, the agent is reading the wrong file or the application isn’t actually writing to the file the agent is monitoring. That’s what makes this step endearing to debugging — you isolate the layer that’s actually broken.

Check what the application is actually writing to. For a Node.js app, that might be console.log() hitting stdout, not a file. The CloudWatch agent by default doesn’t capture stdout unless you configure it explicitly. You might need to redirect output to a file or adjust the config to use systemctl logs or container logs instead.

Test the fix with a manual log entry

Once you think everything is working, verify it with a forced test. Don’t guess. Push a test log entry and confirm it appears.

Trigger your application to generate a log. If your app is a web server, hit an endpoint. If it’s a worker, run a scheduled task. Then check CloudWatch immediately:

aws logs tail my-app-logs --follow

If the log shows up within a few seconds, you’re done. The fix works. If it doesn’t, one of the earlier layers still has a problem.

Alternatively, you can manually write to the file the agent is monitoring and see if it propagates. On Linux:

echo "test message from $(date)" >> /var/log/myapp.log

Then check CloudWatch again. If this test message appears but your application logs don’t, the agent is working fine — your application just isn’t writing to the right place or isn’t outputting anything at all.

This validation step saved me from spending more time debugging when the issue was actually that my app had a configuration error preventing it from logging. The agent was perfect. Everything was correct. But nothing was being written. The moment I forced a test message through, everything clicked into place.

You now have a repeatable debugging workflow: Start with IAM. Move to agent configuration and process status. Verify log group existence. Test with real data. Most missing logs fall into one of these categories, and working through them in order eliminates the guesswork.

“`