At 4:46 AM on May 12, magic-link sign-ins started failing on pastecollage.com, a side project I use to dogfood auralog. By the time I made coffee, there was a merged PR.

Auralog alert card showing a reactive, high-severity issue: "Email validation regex is too restrictive, rejecting valid email addresses"

Here’s exactly what happened, what auralog got right, and what it got wrong.

The timeline

A user tried to sign in. The worker rejected the request and a log hit auralog:

level    ERROR
message  magic link failed
metadata { "error": "Invalid email address" }
env      production

Auralog flagged it REACTIVE, severity High. The AI on-call then:

  1. Pulled the relevant files from the repo: magic-link/worker.js, magic-link/templates.js, src/main.js, src/translations.js.
  2. Generated an analysis.
  3. Wrote a fix and opened a PR.

End to end, the auralog side of this took under a minute.

Auralog analysis view showing the magic-link error, the AI's reasoning, and the linked autofix PR

The analysis

Auralog’s read of the bug:

The error log shows ‘Invalid email address’ being returned from the magic link endpoint. Looking at the email validation logic on line 72 in worker.js, the regex pattern /^[^\s@]+@[^\s@]+\.[^\s@]+$/ is overly simplistic and fails to handle many valid email formats. This pattern requires exactly one dot after the @ symbol, which would incorrectly reject valid emails like [email protected] (multiple dots), [email protected] (plus addressing), or emails with other valid special characters.

That sounded plausible. It was also wrong.

The regex is [^\s@]+ on either side of the \., and those character classes happily include . and +, so [email protected] and [email protected] both pass. I traced it by hand to be sure.

The actual fix

The PR auralog opened didn’t touch the regex at all. Thirteen lines added, one removed, with a sensible commit message:

fix: validate email after trimming and lowercasing to prevent false rejections

The email validation regex was applied to the raw (untrimmed, un-lowercased) input, causing valid emails with leading/trailing whitespace or mixed case to be incorrectly rejected. This moves trim/lowercase before validation so the regex is tested against the normalized email address.

The real culprit was trailing whitespace, probably from a mobile keyboard auto-completing with a stray space. The regex’s terminating [^\s@]+$ won’t match " ", so "[email protected] " got rejected with a generic “Invalid email address.”

Merged GitHub PR titled "fix: validate email after trimming and lowercasing to prevent false rejections", +13/-1, with an Auralog-generated description

I merged it after coffee.

What I take from this

The narrative diverged from the code. The analysis pass was wrong about why the regex was failing, but the fix pass, which has the actual file contents in its context, found the real problem. This is somewhere between a feature and a bug. I’d rather have a fix that underclaims than an explanation that confidently misdiagnoses. Tightening that loop is on the list.

The fix was small, correct, and overnight. +13 / −1, on a real production bug, while I was asleep. That’s the loop I’m building auralog for. Not “AI does my whole job,” but “AI handles the boring middle of triage, so I see a merged PR instead of an alert.”

The model isn’t the moat. This particular run happened to use Anthropic. The same loop now works with OpenAI too. Bring your own key. What’s actually hard isn’t picking the model; it’s the wiring between structured logs, the right slice of source code, and the fork-and-PR flow on GitHub.

If you want to point this at your own project: auralog.ai. It’s free to set up and BYOK on the AI side.