Regex Patterns You'll Actually Use in DevOps
90% of regex in DevOps work falls into a handful of recurring patterns. Memorize these and you'll skip most of the trial-and-error:
- IPv4:
\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b - UUID:
[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} - ISO 8601 timestamp:
\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2} - Log level:
\b(DEBUG|INFO|WARN|ERROR|FATAL)\b - Email (loose):
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
Regex Flags Cheatsheet
g— global (match all occurrences, not just the first)i— case-insensitivem— multiline (^and$match line boundaries)s— dotall (.matches newlines)u— Unicode (treat pattern as Unicode codepoints)
Greedy vs Lazy Matching
By default, quantifiers are greedy: .* matches as much as possible. Add ? to make it lazy: .*? matches as little as possible. This matters for parsing structured text. For example, <.*> applied to <a>b</a> matches the whole thing; <.*?> matches just <a>.
Common Pitfalls
- Escaping the dot —
.matches any character. To match a literal dot, use\. - Anchors —
^matches start,$matches end. Without them, regex matches anywhere in the string. - Catastrophic backtracking — patterns like
(a+)+on long inputs can hang for seconds. Test with malicious input. - Don't parse HTML/JSON with regex — use a real parser. Regex works for simple extraction; full parsing breaks on edge cases.