Introduction

CloudWatch Logs filter patterns let you match only the log events you care about. They are used in places such as metric filters, subscription filters, and log searches, so understanding the syntax is the difference between a useful alert and noisy, misleading monitoring.

Start with the Three Main Pattern Styles

CloudWatch filter syntax is easiest to understand if you split it into three common cases:

• unstructured text matching
• JSON field matching
• space-delimited field matching

Each style is aimed at a different kind of log line. If your application already emits JSON, JSON patterns are usually the cleanest and least error-prone option.

Matching Plain Text Log Lines

For simple text logs, a filter can match terms that appear in the event message.

ERROR

That pattern matches log events containing the word ERROR. This is useful for quick tests, but plain text patterns become brittle fast because they depend on message wording instead of structured fields.

For example, a line such as this would match:

2026-03-07 12:31:44 ERROR Payment failed for order 9812

Plain text patterns are best when you do not control the log format or when you need a very quick signal.

Matching JSON Logs

JSON logs are much more powerful because CloudWatch can match specific fields. A filter pattern for an application that emits structured logs might look like this:

{ $.level = "ERROR" }

That means "match log events where the JSON field level equals ERROR."

You can combine multiple conditions:

{ $.level = "ERROR" && $.service = "billing" }

Numeric comparisons also work:

{ $.latency_ms > 1000 }

And you can check for field existence:

{ $.request_id = * }

If your logs look like this:

1{
2  "level": "ERROR",
3  "service": "billing",
4  "latency_ms": 1420,
5  "request_id": "abc-123"
6}

all three of those filters can be useful in different alarms or dashboards.

Matching Space-Delimited Logs

CloudWatch also supports patterns for logs that are structured by positions rather than JSON keys. A classic example is an access log with fields in a fixed order.

[ip, user, timestamp, request, status_code = 500, bytes]

This tells CloudWatch to parse the log line into fields and then match only events where the field in the status_code position equals 500.

That works well for Nginx-style or Apache-style log formats where the field order is stable but the logs are not JSON.

Use Patterns Where They Fit Best

A practical monitoring setup might look like this:

• text pattern for a quick one-off search
• JSON filter for durable alerts and dashboards
• space-delimited filter for legacy infrastructure logs

If you are building a new application, emitting JSON logs is usually worth the effort. The filter syntax becomes clearer, and the resulting metrics are much easier to maintain.

Testing a Filter Before You Trust It

One of the easiest mistakes in CloudWatch is creating a filter that looks correct but matches too much or too little. Always test the pattern against real sample log lines in the console before turning it into an alert.

A good filter is specific enough to avoid false positives but not so strict that a harmless formatting change makes it miss real failures.

Common Pitfalls

The most common mistake is mixing JSON syntax with plain text logs. A pattern such as { $.level = "ERROR" } only works if the log event really is JSON with that field.

Another problem is using human-readable message text for durable monitoring. Text messages change often, so alerts tied to exact wording tend to break quietly over time.

Field names are also case-sensitive. If your logs use Level but the filter expects level, the pattern will not match.

Finally, be careful with numeric comparisons. A field logged as a string is not the same thing as a numeric field in a structured log event.

Summary

• CloudWatch filter patterns are typically used against plain text, JSON, or space-delimited log formats.
• JSON patterns are usually the best choice for production monitoring because they target named fields directly.
• Plain text filters are quick but fragile, because they depend on message wording.
• Space-delimited patterns are useful for fixed-position logs such as access logs.
• Test every pattern against real sample events before using it in alarms or metrics.