DEV Community: Ghezam Capital

Catching visual regressions between deploys with two API calls

Ghezam Capital — Sat, 03 Oct 2026 11:54:14 +0000

I build Screenshot Happy, so take this with that in mind. This post is about a problem I kept running into on client sites: something looks fine in code review, ships on Friday, and nobody notices the broken hero section until Monday.

The gap between "tests pass" and "it looks right"

Unit and end-to-end tests tell you the logic works. They rarely tell you the page still looks right: a CSS change that pushes the pricing table off-screen, a third-party script that covers the checkout button, a banner that disappears. Catching that usually means keeping your own headless Chrome somewhere, which is its own maintenance job.

Option 1: capture after a deploy (works on any plan)

You can take a screenshot of the page from your CI job with one request and store it as a build artifact:

curl "https://screenshot-api-production-ffd7.up.railway.app/screenshot?url=https://example.com&full_page=true" \
  -H "x-api-key: YOUR_API_KEY" \
  --output after-deploy.png

full_page=true captures the whole scrollable page (capped at 30,000 px), and selector lets you capture just one element, for example the pricing table. Output can be PNG, JPEG or PDF. The request times out after 15 seconds, so it suits public pages, not slow authenticated flows.

Option 2: let a monitor watch the page for you

If you want to be told when a page changes visually between deploys, create a monitor and point it at any webhook you control:

curl -X POST "https://screenshot-api-production-ffd7.up.railway.app/monitors" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "webhook_url": "https://your-server.com/webhook",
    "frecuencia_minutos": 360,
    "umbral_diferencia": 5
  }'

Here frecuencia_minutos is 360 (every 6 hours, the free plan's floor; paid plans go lower). Each check compares the new capture against the last one. If the percentage of changed pixels crosses umbral_diferencia, we POST this to your webhook:

{
  "monitor_id": 4,
  "url": "https://example.com",
  "comprobado_en": "2026-09-18T17:00:00.000Z",
  "cambio_detectado": true,
  "diferencia_porcentaje": 12.4
}

From there it's yours: post to Slack, open a ticket, or trigger an n8n workflow from a webhook node. The delivery is retried up to 3 times if your endpoint doesn't return a 2xx.

What it doesn't do (yet)

I'd rather you know before you build on it:

The threshold is a flat percentage of changed pixels across the whole page. A rotating ad or a live timestamp counts toward it, so noisy pages need a higher threshold.
There is no selector-scoped comparison for monitors; selector only scopes the capture itself.
Checks run on a schedule (every 6 hours on the free plan, hourly on Starter), not the instant you deploy. For a "right after deploy" check, use option 1.
Monitor checks run one at a time across the service, so the frequency is a target, not a real-time guarantee.

Pricing, in one line

Free is €0 with 200 screenshots a month and 3 monitored pages. Starter is €9 and Growth is €29, each combining screenshots and monitoring in one payment. If you hit a limit you get a clear 429, not a surprise charge.

The full parameter list and examples are in the docs: https://screenshot-api-production-ffd7.up.railway.app/docs?utm_source=devto&utm_medium=article&utm_campaign=b7-visual-regression

If you try it on a page where the diff is noisy, tell me which page type and I'll look at whether the threshold logic should change.

Turning a URL into a PDF (and catching when it changes) with one API call

Ghezam Capital — Mon, 28 Sep 2026 14:39:41 +0000

A lot of "URL to PDF" code starts the same way: spin up Puppeteer or Playwright, open the page, call page.pdf(), hope the layout survives headless rendering. It works, until it's the one script nobody wants to touch because it depends on a specific Chromium version.

I added PDF output to Screenshot Happy mostly because I kept needing it for the same reasons I needed screenshots: invoices-as-pages, saved copies of terms/pricing pages, "here's what this looked like" archiving.

The request

Same endpoint as the PNG/JPEG capture, just a different format:

curl -G "https://screenshot-api-production-ffd7.up.railway.app/screenshot" \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "url=https://example.com" \
  -d "format=pdf" \
  -d "full_page=true" \
  -o page.pdf

format=pdf renders the page as it actually looks on screen — not a print stylesheet. Add full_page=true if you want one page sized to the whole scrollable content instead of just the viewport. It's not compatible with selector (that one's PNG/JPEG only, for grabbing a single element).

The other half: knowing when the page changes

Capturing a page once is easy. The harder question is usually "did this change since last time, and do I need to know about it?" That's what /monitors is for — same capture engine, running on a schedule:

curl -X POST "https://screenshot-api-production-ffd7.up.railway.app/monitors" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "webhook_url": "https://your-server.com/webhook",
    "frecuencia_minutos": 60,
    "umbral_diferencia": 5
  }'

It screenshots the URL on that interval, diffs the new capture against the last one, and POSTs to your webhook only when the difference crosses the threshold (umbral_diferencia, percent of changed pixels). No polling loop to write, no image-diffing library to pick and maintain.

Where this is actually useful

QA / visual regression — capture a page (or a specific element via selector) before and after a deploy and diff them, without keeping a headless browser alive in CI.
Archiving — a PDF snapshot of a contract, terms page or listing at a point in time.
Competitive/vendor tracking — get a webhook when a competitor's pricing page or a vendor's ToS actually changes, instead of checking manually.

Limits, honestly

Free tier is 200 screenshots/month and 3 monitored pages checked every 6h — enough to try it, not enough to run serious production monitoring on. Paid plans (from €9/month) raise both the screenshot quota and the check frequency, and add webhook alerts. Full parameters and error codes are in the docs.

If you're already generating PDFs or diffing screenshots with your own Puppeteer/Playwright setup and it's working fine, this isn't trying to talk you out of that. If you're the one who gets paged when that setup breaks, this is meant to remove that job, not replace a tool you like.

Curious whether people doing visual regression testing today are rolling their own diffing, or using a dedicated tool for it — what does that stack actually look like for you?

If you're still maintaining your own Playwright/Puppeteer screenshot service, here's what it usually costs

Ghezam Capital — Tue, 22 Sep 2026 19:55:43 +0000

The pattern

If you've built your own screenshot service on Playwright or
Puppeteer, this list probably looks familiar:

Zombie Chromium processes eating RAM after a crash (a cron job that runs kill -9 on stray browser processes is a common fix — see this writeup)- Memory creeping up until the box gets OOM-killed
A hard ceiling on concurrent pages before things degrade
Someone has to own the 3am page when it falls over

None of this means Playwright/Puppeteer are bad tools — they're not.
It means running them reliably in production is its own job, on top
of whatever you're actually building.

What I built instead

Screenshot Happy is a hosted screenshot API. It still runs Playwright
under the hood — we haven't reinvented that part. What changes is who
owns keeping it alive: GET /screenshot?url=... → PNG/JPEG/PDF, full
page or a CSS selector, custom viewport. Free tier: 200 screenshots/
month, no card.

The other thing it does, if you need it: POST /monitors — point it
at a URL with an interval and a webhook, it screenshots on schedule,
diffs against the last capture, and calls your webhook when something
changes.

Honest caveat

This is a small, new project — a handful of competitors have been at
this longer (ScreenshotOne, Urlbox, ApiFlash among others). If you're
already happy maintaining your own setup, this isn't trying to talk
you out of it. If you're tired of owning the infra side of it, this
is for that.

Docs: https://screenshot-api-production-ffd7.up.railway.app/docs?utm_source=devto&utm_campaign=infra-fatiga

Curious if this pattern (self-hosted Playwright → managed API) matches
what others have run into, or if I'm overestimating how common it is.

You don't need to run your own Playwright/Puppeteer setup just for screenshots

Ghezam Capital — Tue, 22 Sep 2026 13:45:34 +0000

A lot of teams end up running their own headless browser just to generate
a PNG or a PDF of a page. It starts as a few lines of Puppeteer or
Playwright code. It doesn't always stay that simple.

Where it usually goes

Once a screenshot script moves from your laptop into production, it
tends to pick up a few jobs it didn't have before:

- - Keeping Chromium processes from piling up after a crash or a timeout
- - Watching memory, because a long-running headless browser process can
- grow over time
- - Capping how many pages run at once, since concurrency has a ceiling
- before things degrade
- - Owning the alert when a job queue backs up or a page never returns

None of this means Playwright or Puppeteer are broken tools — they're
not. Most hosted screenshot services, this one included, are built on
top of them. It just means that once it's running unattended, "take a
screenshot" quietly turns into "run and babysit a browser," which is a
different job than the one most people signed up for. This writeup
from someone who ran Puppeteer screenshots in production for six months
is a good look at what that job actually involves day to day.

What Screenshot Happy does differently

Screenshot Happy is a hosted API. It still runs Playwright under the
hood — that part isn't magic, it's the same tool everyone else uses.
What changes is who's responsible for keeping it alive:
GET /screenshot?url=... returns a PNG, JPEG or PDF. You don't
provision, patch, restart, or clean up after it.

If you also need to catch when a page changes — a competitor's
pricing, a vendor's terms — there's a scheduling mode too, but that's
a separate feature, not the point of this post.

Free tier: 200 screenshots/month, no card required, if you want to see
what the output actually looks like before deciding anything:
https://screenshot-api-production-ffd7.up.railway.app/docs?utm_source=devto&utm_medium=article&utm_campaign=playwright_infrastructure

Honest caveat
This is a small, recently-launched project. There are more established
screenshot APIs out there (ScreenshotOne, Urlbox, ApiFlash among
others) that have been doing this longer, and I'm not going to pretend
otherwise. If your current setup works and nobody's getting paged for
it, there's no real reason to switch. This is aimed at the setups
where that's not quite true anymore.

Question

If you're running your own Playwright/Puppeteer screenshot service
today — is infrastructure actually the annoying part, or is it
something else (accuracy, speed, cost)? Genuinely curious where this
breaks down for people who've actually dealt with it.

[Boost]

Ghezam Capital — Mon, 21 Sep 2026 19:16:39 +0000

Ghezam Capital

Sep 21

I built a screenshot API that can also tell you when a website changes

#showdev #productivity #javascript #api

1 min read

I built a screenshot API that can also tell you when a website changes

Ghezam Capital — Mon, 21 Sep 2026 16:11:15 +0000

I kept finding myself writing small Playwright/Puppeteer scripts whenever I needed screenshots of websites.

So I decided to turn that into an API.

Screenshot Happy can generate:

PNG, JPEG and PDF screenshots
Full-page screenshots
Screenshots of specific elements using CSS selectors
Custom viewport sizes
Automated website monitoring
Webhooks when a monitored page changes
The monitoring part is what made the project more interesting to me.

For example, you could monitor:

A competitor’s pricing page
Documentation
Terms and conditions
Product pages
Any webpage where you need to know when something changes
The API can detect a visual change and send a webhook instead of requiring you to constantly check the page yourself.

There’s a free plan with 200 screenshots/month and 3 monitored pages, so you can try it without paying.

I’m currently trying to figure out whether the monitoring side is actually useful enough for developers to use regularly.

If you work with Playwright, Puppeteer, testing, monitoring or web automation:

What would you want an API like this to do that it doesn’t do yet?

I’d genuinely appreciate feedback, especially if you think the idea is useless. Those comments are usually more valuable than “looks cool.” 😅

Docs: https://screenshot-api-production-ffd7.up.railway.app/docs
_