Testing regex where it's safe
Nothing you paste here is uploaded, which matters, because the text you test regex against is usually production log lines, and production log lines are full of IPs, emails and tokens. The engine is your browser's native JavaScript regex implementation, so behaviour matches Node.js exactly and is close to (but not identical to) PCRE used by grep -P, nginx and PHP.
Flags in thirty seconds
g finds all matches instead of the first. i ignores case. m makes ^ and $ match at every line boundary rather than only the string ends, essential when testing against multi-line log excerpts. s lets . match newlines too, which is what you want when a pattern must span lines.
Dialect differences that bite sysadmins
JavaScript regex lacks a few PCRE features: no possessive quantifiers, no \K, and lookbehind only in modern engines. Conversely, plain grep/sed use POSIX basic/extended syntax where \d doesn't exist (use [0-9] or [[:digit:]]) and + needs escaping in basic mode. A pattern verified here will usually work in grep -P, awk and most languages, but always sanity-check shell-tool syntax.
A word on catastrophic backtracking
Patterns with nested quantifiers like (a+)+$ can take exponential time on non-matching input, enough to hang a browser tab here, or peg a CPU core in production (the classic ReDoS). If a test seems to freeze, that's your answer: rewrite the pattern with atomic structure (avoid a quantifier applied to a group that itself ends in a quantifier over the same characters).