DEV Community: SiteBrief

Why "flex" breaks your email in Outlook (and how to catch it in VS Code)

SiteBrief — Tue, 26 May 2026 13:07:35 +0000

You spent hours building a beautiful email template with Tailwind CSS.
Flex layout, rounded corners, smooth animations. Looks perfect in the browser.

Then it lands in Outlook. Complete disaster.

The problem

Outlook 2016/2019/2021 uses Microsoft Word as its HTML renderer.
Word doesn't understand modern CSS. At all.

These Tailwind classes silently do nothing in Outlook:

Class	Why it breaks
`flex`, `inline-flex`	No flexbox support in Outlook Windows
`grid`, `grid-cols-*`	No CSS Grid support
`rounded-*`	`border-radius` is ignored
`animate-*`	No CSS animations
`shadow-*`	No `box-shadow` support
`gap-*`	Requires flex/grid (both unsupported)
`w-screen`, `h-screen`	No `vw`/`vh` units

The worst part? No errors. No warnings. Just broken layouts.

The fix

I built an ESLint plugin that catches these issues right in VS Code —
before you send anything.

bash

npm install --save-dev eslint-plugin-email-safe

// eslint.config.js
import emailSafe from 'eslint-plugin-email-safe'

export default [
  {
    files: ['emails/**/*.{jsx,tsx}'],
    ...emailSafe.configs.recommended,
  }
]

Now flex, grid, rounded-lg get underlined instantly:
"rounded-lg" (border-radius) is not supported in: Outlook Windows.
Details: https://www.caniemail.com/features/css-border-radius/
89 unsafe patterns detected. Works with cn(), template literals,
and conditional expressions out of the box.

Bonus: Tailwind plugin with MSO utilities

npm install --save-dev tailwind-email-safe

// tailwind.config.js
module.exports = {
  plugins: [require('tailwind-email-safe')],
}

Adds Outlook-safe utilities you actually need:

<table class="email-table w-full max-w-email-md mx-auto">
  <tr>
    <td class="email-td mso-lh-exact p-6">
      <img class="email-img" src="logo.png" />
      <p class="font-email-sans text-base">Hello!</p>
    </td>
  </tr>
</table>

email-table — resets MSO table spacing
mso-hide — hides element from Outlook only
mso-lh-exact — fixes line-height in Outlook
email-img — removes gaps under images
max-w-email-md — standard 600px email width
How the compat matrix stays up to date
The compatibility data comes from caniemail.com.

A weekly AI agent (Claude) monitors Gmail, Outlook, and Apple Mail
release notes for CSS changes. If something changes — it auto-updates
the matrix and opens a PR.

No manual maintenance needed.

GitHub: https://github.com/PasateArtem/email-safe

Free and open source. Would love feedback from people building emails!

I built a tool that detects broken security headers, missing robots.txt, and WP_DEBUG=true — then opens a PR to fix them automatically

SiteBrief — Thu, 21 May 2026 16:20:43 +0000

Every agency I've talked to has the same story.

Client calls on a Friday. Site is down or flagged by Google Search Console. You SSH in, find WP_DEBUG = true in production, turn it off, deploy, done. Twenty minutes gone. Next week, different client, same thing.

I run a small web agency tool called SiteBrief — it monitors uptime, SSL, PageSpeed, SEO, and security headers across client sites. After six months of watching the same issues appear on the same types of sites, I built DevLab: a section that not only detects problems but generates the fix and opens a GitHub PR (or GitLab MR) for your review.

The workflow

Detect → Explain → Preview fix → Open PR → You approve

Detect — SiteBrief continuously scans for security header gaps, SEO problems, PageSpeed issues, WordPress misconfigs, broken crawl settings
Explain — every issue gets a plain-English description, severity level, and a confidence score (more on that below)
Preview fix — click "Preview fix" and you see the exact file, the exact change, and what it will do — before anything happens
Open PR — confirm in the modal, SiteBrief opens a pull request on your repo with a descriptive title, full context in the body, and a dedicated fix branch
You approve — review the diff on GitHub/GitLab as you normally would. Nothing merges automatically.

Confidence scores

This was the part I spent the most time thinking about. "AI generates fixes" sounds scary. The honest answer is: some fixes are deterministic (swap true for false in one line), others are educated guesses (write an SEO title for a site you've never seen).

So every fix has a confidence score:

| Issue                        | Fix                                      | Confidence |
|------------------------------|------------------------------------------|------------|
| WP_DEBUG = true              | define('WP_DEBUG', false) in wp-config   | 95%        |
| robots.txt missing           | Valid file with User-agent: * / Allow: / | 90%        |
| Missing security headers     | HSTS, X-Frame-Options, CSP               | 88%        |
| Missing viewport / canonical | Correct meta tag added                   | 85%        |
| No cache headers             | Cache-Control: max-age=31536000          | 75%        |
| Missing SEO title/desc       | Placeholder — needs your review          | 62%        |

Green (≥85%) = safe to merge after a quick look. Amber (≥70%) = test on staging. Orange (<70%) = treat as a starting point, edit before merging.

Auto-detecting the right file
One thing I didn't want to do: assume everyone is on Netlify.

When DevLab generates a security header fix, it reads your repo and tries candidate files in order:

netlify.toml → adds a [[headers]] block
.htaccess → adds Header always set inside mod_headers
nginx.conf (or nginx/default.conf) → injects add_header into the server block
For SEO fixes it detects the framework:

Next.js App Router → edits app/layout.tsx using the metadata export
Plain HTML → injects tags into

Why I built the preview step
My first instinct was to make "Generate PR" a single button. Ship it, done.

Then I showed it to three agency owners. All three asked: "But what exactly is it going to change?" That was the signal. Nobody wants a black box touching client repos.

So now the flow is:

Click "Preview fix"
Modal shows: action description, exact file path, confidence bar with color coding, a safety note ("this adds headers to netlify.toml — it will not touch your application code"), and the "Nothing merges automatically" guarantee
Click "Open PR" to proceed — or just close the modal
The PR opens on a dedicated branch (sitebrief/fix-security-headers style), so it's isolated and easy to close if you change your mind.

One-click rollback
If you open a PR and then decide against it, there's a Close button directly in the DevLab history panel. It calls GitHub's PATCH /pulls/{number} (state: closed) or GitLab's PUT /merge_requests/{iid} (state_event: close) and marks the fix as rolled back in our records.

No need to go to GitHub just to close a PR.

What's next
Short-term:

Staging branch deploys — open the fix PR against a staging branch, not main
Dependency security updates — scan package.json / composer.json, PR with safe version bumps
Scheduled digest — weekly email: all issues + open fix PRs across your portfolio

If you run a dev shop with multiple client sites and you're tired of playing whack-a-mole with the same misconfigs every month — that's exactly who DevLab is for.

Happy to answer questions about the implementation, the PR flow, or how the file detection works.

https://sitebrief.net/

Why your clients find out about site downtime before you do

SiteBrief — Wed, 20 May 2026 19:03:40 +0000

It's 9:07 AM on a Tuesday. Your phone rings. It's a client.

"Hey, our website is down. Has been for a couple hours. Can you look into it?"

You open your laptop, type in the URL, and there it is — a blank white page, or worse, a 500 error. The client knew before you did. Again.

The real reason clients find out first

It's not because you're bad at your job. It's because you're not watching every site, every minute of every day. That's not humanly possible.

Clients visit their own site constantly — first thing in the morning, before a meeting, after sending someone a link. The moment something breaks, they see it. Meanwhile, you might not check a client's site for days unless there's a reason to.

That's the gap — and it costs you trust every single time.

What makes it worse: silent downtime

Not all downtime is dramatic. Sometimes the site looks fine but returns a 500 error on certain pages. Sometimes an SSL certificate expired and Chrome shows a red warning — visitors leave, but you had no idea.

A plugin update broke the checkout — but not the homepage
A hosting provider had a partial outage affecting only certain regions
The domain renewal lapsed and the site stopped loading
WP_DEBUG was accidentally left on, leaking database errors in the page source

These slip through without monitoring. By the time someone notices, it's been hours.

How to get ahead of it

You need to be notified the moment something goes wrong — before anyone else sees it.

For agencies managing multiple client sites, the checklist:

Uptime monitoring — checks every minute from multiple locations, alerts within seconds
SSL & domain expiry — alerts 30 days before anything expires
Response time tracking — catch slow sites before clients notice performance issues
WordPress health — outdated plugins, PHP version, WP_DEBUG status, health score 0–100 per site
Maintenance task board — when something breaks, create a task right from the alert

The business case

When you catch an issue before the client does, you're not firefighting — you're delivering value. Monthly uptime reports, proactive plugin updates, SSL renewals handled weeks early. That's what justifies a retainer.

Agencies that monitor proactively charge more, retain clients longer, and spend less time on damage control.

I built SiteBrief to solve exactly this. Free plan covers 20 sites, no credit card needed.

What's your current monitoring setup? Would love to hear how others handle this.