Ran into a situation last week that got me thinking about how most teams handle visual changes in production.

We pushed a CSS update that was supposed to fix button alignment on one page. Looked fine in staging. Looked fine in the PR preview. Got merged, deployed, and broke the card layout on three other pages because of a shared utility class.

Caught it about four hours later when a customer mentioned it in a support ticket. Not a great look.

What we tried

After that incident we talked about adding visual regression testing to CI. Looked at a few options:

• Percy — solid, but the pricing gets steep once you have more than a handful of pages and multiple PRs a day

• Playwright screenshots in CI — free, but you need to maintain baseline images and the diffs are noisy. Every font rendering difference across runners triggers a false positive

• Manual spot checks after deploy — what we were doing. Obviously not sufficient

We ended up going with Playwright screenshot comparisons but with a pretty generous diff threshold (0.3%) to cut down on false positives. It catches big layout shifts but ignores sub-pixel rendering differences. Good enough for now, but not ideal.

The production monitoring gap

CI-based visual testing only covers what happens before deploy. It doesn't catch things that break after — CDN caching serving old assets, third-party scripts injecting unexpected elements, A/B test variants rendering wrong.

Some teams run synthetic monitoring that takes periodic screenshots of production pages and compares them. That covers the post-deploy gap but it's a separate system to set up and maintain.

Curious what others do

How are you handling visual verification in production? Specifically:

• Do you run any visual checks post-deploy, or only in CI?

• If you use screenshot comparison, how do you deal with dynamic content (dates, user-specific data, ads)?

• Anyone running continuous visual monitoring on production pages on a schedule?

Feels like there should be a simpler answer than "maintain 200 baseline images and pray the CI runner has the same font rendering as last time."

Been dealing with this more often lately. Tests pass on my machine, I push, and CI blows up. Usually it's one of these:

• Different Node/Python/whatever version
• Missing env vars that exist in my .env but not in CI secrets
• File system case sensitivity (macOS vs Linux)
• Some flaky test that depends on timing

My current debugging flow is pretty basic: check the logs, compare versions, run the exact same Docker image locally if I can. But it still eats 20-30 minutes each time before I figure out the actual problem.

Anyone have a more systematic approach? Like a quick checklist you run through before you even look at the logs?

Also curious — do you replicate your CI environment locally with something like act (for GitHub Actions) or just trust the remote runner?

Had a backup script running via cron for months. Worked fine until it didn't — turns out the disk filled up three weeks ago and the job started failing silently. Nobody noticed until we actually needed a restore.

The obvious answer is "check your logs" but let's be honest, nobody's reading cron logs daily for 15 different scheduled tasks across 4 servers.

What's your setup for making sure crons are actually completing? Do you just grep logs periodically, or do you have something more structured? Curious how others handle this without turning it into a whole project.

Honest question. I've got automated daily pg_dump backups going to S3 and I check that the files are there, but I've never actually tried restoring one on a fresh instance to see if it works.

Feel like this is one of those things where you assume it's fine until you desperately need it and find out the dumps were corrupted for 3 months.

Anyone have a setup where restores get tested automatically? Or is that overkill for side projects?

Spent an hour today renaming env vars across three services to make them "consistent." Broke staging in the process because one service cached the old values. Should've just left the mess alone — it worked fine before I touched it.

Working on a project where I need to grab screenshots of pages on a schedule — mostly for QA and keeping a visual history of what changed and when.

Right now I'm running Puppeteer in a cron job on a cheap VPS. It works, but honestly it's a pain to maintain. Chromium eats RAM like crazy, sometimes it hangs and the whole thing needs a restart, and the screenshots come out wrong on pages that load content dynamically.

A few things I've been struggling with:

• Pages with lazy-loaded images — half the time the screenshot fires before everything renders
• Cookie consent banners blocking the actual content
• Memory usage goes through the roof when I try to do more than ~50 pages in a batch

I've looked into Playwright as a replacement but from what I can tell the resource usage is about the same. Also tried running headless Chrome in Docker which at least makes cleanup easier, but didn't solve the core problems.

Curious what others are using. Are screenshot APIs worth it for this kind of thing, or is self-hosting still the way to go? Anyone running something similar at scale?

I run a few side projects and I've gone through different stages of monitoring them. First it was just checking manually if the site loads. Then I added a simple curl ping in cron. Then I started tracking response times, certificate expiry, even visual changes on pages.

At some point I realized I was spending more time building monitoring than the actual product. Classic trap.

Curious what other devs use for keeping an eye on their stuff. Do you go with a hosted service, self-host something like Uptime Kuma, or just wing it with scripts?

Hey everyone! Just signed up on Lemmy. I've been running self-hosted services for a while now and looking forward to learning from this community. Glad to be here.