I Turned an Old HP Laptop Into a Linux Automation Server and Learned Why Browser Automation Is a Liar

There is a very specific kind of optimism that makes you look at a dying 2015 HP laptop and think:

“Yeah. This should run production browser automation.”

This thing had:

• 6 GB RAM
• a mechanical hard drive
• integrated AMD graphics
• the general aura of a haunted library computer

I had already memorized Alt + PrintScreen + REISUB because the machine had seen things.

Naturally, I decided to turn it into a self-hosted automation server running Playwright workers for PostPunk.

And honestly?

At first, it mostly worked.

The Linux side was fine. Queue workers were fine. Background jobs were fine. Firefox behaved surprisingly well.

Then Chromium entered the chat and everything became spiritually unstable.

The Problem Wasn’t Immediate

The annoying part is that the automation sometimes worked.

Pinterest would post.
Facebook would post.
Dev.to would post.

Then suddenly:

• selectors would fail
• pages would flicker
• interactions would stop working
• rendering would glitch out
• Chrome would randomly pixelate the display

And the best part?

Rebooting the machine fixed it for about ten minutes.

Which is one of the worst debugging outcomes possible because it tricks you into thinking you solved something.

Headed vs Headless Was the Real Trap

At first I tested everything with a visible browser because I like seeing automation happen.

Honestly, most developers do.

Watching the browser click through workflows makes the system feel real. You can visually confirm:

• login state
• navigation
• selectors
• button clicks
• page rendering

But on this machine, visible Chromium was apparently part of the problem.

Headed mode flickered constantly. Sometimes opening multiple windows would cause random visual corruption. Firefox looked normal. Chromium behaved like it had unresolved personal issues with Linux.

Ironically, once I moved more flows to headless mode, reliability improved.

Not because the automation logic changed.

Because the machine stopped trying to visibly render Chrome on ancient hardware held together by optimism and thermal paste.

Headless and Headed Browsers Are Not Really the Same

People talk about headless Chrome like it is just:

“Chrome without the window.”

That is a comforting lie.

Headless and headed runs differ in:

• rendering behavior
• GPU paths
• timing
• compositor behavior
• resource usage
• sandboxing
• viewport defaults

On modern hardware, those differences are annoying.

On old hardware, those differences become a horror genre.

This laptop was running:

• a spinning HDD
• integrated Radeon R6 graphics
• limited RAM
• multiple worker processes
• Playwright automation

That is exactly the kind of setup where browser rendering starts acting cursed under load.

Linux Makes Browser Automation More Honest

Linux is great because it exposes every hidden assumption your workflow was making.

A browser launched manually from your terminal is not living the same life as:

• a headless browser
• a system service
• a scheduled worker
• an unattended automation process

Once I started debugging seriously, I ended up deep in the usual Playwright rabbit hole:

• screenshots
• tracing
• Chromium launch flags
• disabling GPU paths
• sandbox weirdness
• comparing headless vs headed runs
• logging everything to Telegram because the local logs were not helpful enough

Some of the flags that helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox'
  ]
});

And yes:

npx playwright install-deps

ended up mattering more than I wanted it to.

The Machine Had Vibes

Every self-hosted setup eventually develops a personality.

This one had raccoon energy.

It worked just well enough to encourage confidence right before doing something deeply suspicious.

Firefox? Fine.

Chromium?
Flickering like a cursed artifact from a forgotten Best Buy clearance aisle.

At some point I stopped treating the server like infrastructure and started treating it like a slightly unstable coworker that needed supervision and good logging.

What Actually Improved Reliability

The biggest improvement was honestly:

• moving more automation to headless mode
• improving logging
• adding Telegram notifications
• testing under actual production conditions instead of “works while I’m watching it”

That last one matters.

Because “works on my machine” means almost nothing in browser automation when:

• the hardware changes
• the rendering path changes
• the browser mode changes
• the workload changes

Browser automation is part application logic and part environmental superstition.

Old hardware amplifies that reality fast.

Lessons Learned

A few things I would absolutely do again:

• keep a visible debug mode available
• capture screenshots aggressively
• log browser launch args
• test under the exact conditions production uses
• assume old hardware will surface weird rendering bugs earlier

And a few things I learned the hard way:

• headed success does not prove headless reliability
• Chromium on aging Linux hardware gets weird fast
• rebooting is not a debugging strategy
• self-hosted automation needs observability way more than optimism

I still like the setup.

Repurposing old hardware into useful infrastructure is genuinely fun.

But browser automation was the thing that forced honesty into the system.

The stack looked stable right up until Chromium had to behave unattended on a 10-year-old Linux laptop with a mechanical hard drive and trust issues.

That’s when the project stopped being a fun experiment and started becoming engineering.

The Bug Only Existed When Nobody Was Watching

There is a special kind of insult that only browser automation can deliver.

You build a Playwright workflow.
You test it manually.
You watch the browser open, click, type, submit, navigate, succeed.

Everything looks solid.

Then you run the exact same flow in production, headless, unattended, on the actual worker machine, and it falls apart like it has never seen a DOM before.

That was the bug.

It only existed when nobody was watching.

And yes, that is an incredibly annoying genre of engineering problem.

The Setup

This lived inside a self-hosted content automation stack running on an old HP laptop I repurposed into a Linux worker box for PostPunk.

The stack was basically:

• Linux
• Playwright posting workers
• browser automation for publishing flows
• scheduled background jobs
• queue-driven content automation

The machine itself was already operating mostly on vibes.

It had:

• 6 GB RAM
• a mechanical hard drive
• integrated Radeon graphics
• the general aura of a haunted library computer

The kind of laptop where opening Chrome was basically rolling percentile dice against the gods of thermal management.

I had already memorized Alt + PrintScreen + REISUB because eventually this machine was going to need emotional support.

Naturally, I decided this was suitable production infrastructure.

Because apparently I enjoy problems with texture.

The First Real Sign Something Was Wrong

At first I thought the automation itself was flaky.

Maybe a selector issue.
Maybe timing.
Maybe Playwright weirdness.

Then one night around 3 AM, while manually logging back into one of the platforms, Chromium itself started pixelating.

The screen partially froze.
The UI glitched out.
Everything briefly distorted.
Linux made that horrible little ringing system noise like the machine was actively negotiating with death.

I stopped touching the mouse for a few seconds and eventually the system recovered.

Firefox mostly behaved normally.

Chrome behaved like the laptop was trying to reject it biologically.

That was the moment I realized this was no longer just an automation problem.

The Lie: “It Works Fine”

While visually testing the automation, everything looked perfect.

Headed Chromium launched.
The page loaded.
Selectors resolved.
Buttons clicked.
Posts published.

Pinterest worked.
Facebook worked.
Dev.to worked.

If you watched the browser run manually, you would absolutely think:

“Cool. This is production-ready.”

That was the trap.

Because the moment I switched the same workflows into unattended headless production mode, things became cursed.

Suddenly:

• selectors timed out
• pages rendered differently
• interactions fired but did not land
• uploads silently failed
• waits became inconsistent
• browser state got flaky
• random inputs were skipped entirely
• jobs hung forever for no obvious reason

The automation would sometimes just stop mid-flow like Chromium had emotionally checked out.

Headed and Headless Chromium Are Not the Same Thing

People describe headless Chrome like it is just:

“Chrome without the window.”

That is a comforting lie for people who have not suffered enough yet.

Headed and headless Chromium differ in ways that matter:

• rendering paths
• GPU behavior
• compositor timing
• focus handling
• viewport defaults
• performance under load
• environmental dependencies

On a modern machine, those differences are annoying.

On old Linux hardware, they become plot-relevant.

In headed mode, the visible browser was accidentally helping me.

Rendering slowed things down just enough that:

• animations finished
• panels stabilized
• listeners attached properly
• React stopped rearranging the DOM
• uploads completed before clicks fired

Then headless mode removed all that accidental timing padding.

Suddenly the automation was operating at full machine speed against an unstable environment.

That is where reality started.

The Machine Had Chrome-Specific Hatred

The weirdest part is that Firefox mostly behaved fine.

Chrome specifically was the problem child.

Even opening normal Chrome windows on this machine felt risky.

There was basically a 50/50 chance:

• things would work normally
• the UI would partially freeze
• rendering would glitch
• the system would briefly pixelate
• the browser would become unstable under load

I still do not fully understand why.

Maybe Chromium was hitting GPU paths the laptop hated.
Maybe Linux and Chrome were fighting somewhere deep in the graphics stack.
Maybe the machine itself was simply old and tired.

I genuinely do not know.

At some point debugging old Linux hardware stops being science and becomes folklore.

Timing Bugs Are Worse in Automation

One of the hardest lessons with browser automation is this:

Watching something work manually proves almost nothing.

Manual observation accidentally hides instability.

Humans naturally slow workflows down.
Visible rendering introduces delays.
The environment stabilizes itself while you are watching.

Production workers do not care about your vibes.

Headless Playwright runs at machine speed.

So this:

await page.click('[data-testid="publish-button"]');

suddenly becomes dangerous because the UI might:

• exist visually but not functionally
• still be animating
• still be hydrating
• still be attaching listeners
• still be processing uploads

The bug was not random.

The bug was exposing assumptions I did not realize I had made.

Linux Browser Automation Is Its Own Genre of Suffering

Linux browser automation always includes at least one phase of:

“Which dependency is ruining my life this time?”

Eventually I ended up deep in the usual Playwright rabbit hole:

• screenshots
• tracing
• Chromium launch flags
• sandbox weirdness
• GPU disabling
• headless comparisons
• HTML snapshots
• Telegram alerts
• aggressive logging

Some flags that genuinely helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-background-timer-throttling',
    '--disable-renderer-backgrounding'
  ]
});

And yes:

npx playwright install-deps

ended up mattering way more than I wanted it to.

My Observability Strategy Became “Listen For The Fan”

Before headless mode, I barely cared about my Telegram notifications because I could physically watch the automation run on the screen.

Once everything moved headless, the notifications suddenly became the only proof the system was still alive.

At some points, my entire monitoring setup was basically:

• Telegram alerts
• log files
• listening for the laptop fan spinning up

If I heard the fan kick on, I knew the workers were probably doing something.

Which is not exactly enterprise observability engineering.

Most of this debugging happened around 3 AM while sitting directly in front of the machine like some kind of browser automation goblin waiting to see whether Chromium would survive the night.

The Most Linux Thing I Did

At one point I started deleting Chrome-related Linux components trying to “clean up” the environment.

I removed things I absolutely should not have removed.

X11 desktop pieces.
Chrome shell integrations.
Random Chromium-related packages I barely understood.

Eventually I broke the setup badly enough that I had to reinstall parts of it.

And somehow?

That actually improved stability afterward.

Which is the most Linux sentence I have written in a while.

What Actually Helped

The final “fix” was not one fix.

It was a pile of smaller operational improvements:

• moving workers fully headless
• improving logging
• relying on Telegram notifications
• adding screenshots on failure
• testing under actual production conditions
• waiting on UI state instead of luck
• reducing rendering overhead
• reinstalling the Chrome components I accidentally destroyed

The biggest shift was psychological.

I stopped treating:

“it worked once”

as evidence of reliability.

Because reliability is not:

• “worked on my machine”
• “worked while visible”
• “worked during testing”
• “worked three times in a row”

Reliability means:

• unattended
• repeatable
• observable
• stable under load
• stable overnight
• stable when nobody is babysitting Chromium personally

That is an entirely different standard.

Final Thoughts

I still like this setup.

Repurposing old hardware into useful infrastructure is genuinely fun.

There is something satisfying about turning a neglected old laptop into a working automation server instead of throwing it away.

But browser automation forces honesty into your system very quickly.

The stack looked stable right up until Chromium had to behave unattended on a 10-year-old Linux laptop with trust issues and a mechanical hard drive.

Eventually the workers became stable enough that I stopped staring directly at them while jobs ran.

Honestly, that was probably the real milestone.

Not:

“The script finally worked.”

But:

“I no longer felt emotionally required to supervise Chromium personally.”

Running Playwright + Headless Chrome on Old Hardware Is Less “Automation” and More “Systems Archaeology”

There is a very specific type of developer optimism that makes you look at a dying 2015 HP laptop and think:

“Yeah, this should absolutely run production browser automation.”

This machine had:

• 6 GB RAM
• a mechanical hard drive
• integrated Radeon graphics
• Linux
• Chrome
• trust issues

I had already memorized Alt + PrintScreen + REISUB because eventually this machine was going to require spiritual intervention.

Naturally, I turned it into a self-hosted automation server running Playwright workers for PostPunk.

Because apparently I enjoy creating problems recreationally.

The Basic Fantasy

The fantasy sounds reasonable enough.

Take an old laptop.
Install Linux.
Run some worker processes.
Use Playwright for browser automation.
Queue content posts automatically.
Stop manually posting to platforms one miserable click at a time.

Honestly?

That last part mattered the most.

I’m stubborn, cheap, and deeply allergic to manually posting content platform-by-platform forever.

Which is basically the entire psychological profile required to build self-hosted automation systems.

At some point this stopped being:

“a fun Linux experiment”

and became:

“the engine for how I actually want to work.”

That meant the machine suddenly mattered.

And unfortunately, so did Chrome.

Everything Was Fine Until Chromium Entered The Story

The Linux side was mostly solid.

Workers behaved.
Scheduling behaved.
Queue processing behaved.
Notifications behaved.

Then Chromium showed up and started acting like the laptop was trying to process emotional trauma in real time.

At first the failures looked random:

• selectors timing out
• uploads silently failing
• clicks not landing
• pages freezing
• workers hanging forever
• random skipped inputs
• inconsistent rendering

The worst part?

The automation usually worked while I was watching it.

Pinterest posted correctly.
Facebook posted correctly.
Dev.to posted correctly.

So naturally I thought:

“Cool. Stable.”

That was a lie.

The Moment I Realized This Wasn’t Just A Script Problem

One night around 3 AM, while manually logging back into one of the platforms, Chromium itself started pixelating.

The screen partially froze.
The UI glitched out.
The machine made that horrible little Linux system ringing noise like everything inside the laptop had briefly entered a panic attack.

I stopped moving the mouse.
Waited a few seconds.
The machine recovered.

Firefox mostly behaved normally.

Chrome behaved like the unstable roommate Linux was too polite to evict.

That was the moment I realized:
this was no longer just a Playwright problem.

Something deeper was happening.

Old Hardware Changes Failure Modes

A lot of browser automation advice accidentally assumes healthy hardware.

People say:

“Playwright works great.”

And I believe them.

But there is usually an invisible footnote:

“on hardware that is not actively fighting for its life.”

Old hardware changes the nature of failures.

On modern systems:

• bad waits
• selectors
• auth issues
• flaky timing

On old systems:

• GPU weirdness
• rendering instability
• browser freezes
• memory pressure
• disk latency
• thermal throttling
• random Chrome existential crises

At some point the machine stopped feeling “slow” and started feeling medically concerning.

The fans would suddenly kick on like the laptop had just seen a tax audit.

Opening Chrome on this thing felt less like launching software and more like asking an elderly wizard for one final favor.

Headless Chrome Is Not Lightweight. It Is Just Invisible

People hear “headless browser” and imagine some tiny efficient automation process.

No.

Headless Chromium still wants:

• RAM
• CPU
• rendering resources
• shared memory
• dependencies
• graphics support
• enough system stability to not implode under load

And when resources get tight, the browser does not always fail cleanly.

Sometimes it just becomes weird.

Which is worse.

The browser would get 95% through a workflow and then suddenly remember it was running on archaeology.

That’s the dangerous middle ground:
not broken enough to diagnose instantly,
not stable enough to trust.

Headed And Headless Chromium Are Basically Different Species

This ended up being the biggest lesson.

The workflows behaved differently depending on whether I could physically see the browser.

That sounds fake until you experience it yourself.

In headed mode:

• rendering slowed things down
• animations had time to finish
• uploads stabilized
• UI transitions completed
• the environment accidentally synchronized itself

Headless mode removed all that padding.

Suddenly the automation was running at full machine speed against a browser environment held together with aging hardware and optimism.

That’s when the race conditions showed up.

This:

await page.click('[data-testid="publish-button"]');

turns out to mean absolutely nothing if:

• React is still hydrating
• uploads are incomplete
• event listeners are not attached yet
• the UI exists visually but not functionally

Watching successful automation manually proves almost nothing.

Production workers do not care about your vibes.

Linux Browser Automation Slowly Becomes Folklore

At some point my debugging strategy stopped being engineering and became ritualistic behavior.

I started:

• reinstalling packages I barely understood
• randomly deleting Chrome-related components
• tweaking launch flags endlessly
• waiting before clicks
• comparing screenshots
• listening for fan noise
• praying to God a little bit

At one point I removed enough Chrome/X11-related stuff that the machine started pixelating outside the browser too.

That was probably the strongest:

“hardware may actually be dying”
moment.

Ironically, reinstalling the things I broke actually improved stability afterward.

Which is the most Linux outcome possible.

GPU Weirdness Is Real

Firefox mostly behaved fine on this machine.

Chrome specifically was chaos.

Even normal Chrome windows were basically a 50/50 gamble:

• maybe fine
• maybe flickering
• maybe partially freezing
• maybe pixelating
• maybe emotionally collapsing halfway through rendering

I still do not fully understand why.

Maybe Chromium was hitting rendering paths the machine hated.
Maybe Linux and Chrome were fighting deep in the graphics stack.
Maybe the laptop itself was just old and tired.

At some point debugging old Linux hardware stops being science and becomes folklore.

What Actually Helped

Not one thing.
Several things.

Moving more flows to headless mode helped because visible Chrome rendering was apparently making the machine more unstable.

Proper waits helped a lot.

I learned very quickly that:

• waits matter more than confidence
• “loaded” does not mean “ready”
• visible UI does not mean interactable UI

Some flags that genuinely helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-background-timer-throttling',
    '--disable-renderer-backgrounding'
  ]
});

And yes:

npx playwright install-deps

ended up mattering far more than I wanted it to.

My Observability Strategy Became “Listen For The Fan”

Before headless mode, I barely paid attention to my Telegram notifications because I could physically see the automation running.

Once everything moved headless, the notifications became the only reliable proof the workers were alive.

At one point my monitoring stack was basically:

• Telegram alerts
• screenshots
• log files
• listening for fan noise

If I heard the fan suddenly spin up, I knew the workers were probably doing something.

Which is not exactly enterprise observability engineering.

Most of this debugging happened around 3 AM while sitting directly in front of the machine like some kind of browser automation goblin trying to convince Chromium not to explode overnight.

Reliability Is A Much Higher Standard Than “It Worked Once”

This was the real lesson.

A successful run does not prove reliability.

It proves:

one run succeeded under one set of conditions.

That’s all.

Reliable automation means:

• unattended
• repeatable
• observable
• stable under load
• stable overnight
• stable when nobody is staring directly at Chromium like a nervous zookeeper

That is a completely different standard.

Eventually the workers became stable enough that I stopped compulsively checking them every few minutes.

Honestly?

That was probably the real milestone.

Not:

“the scripts worked.”

But:

“I no longer felt emotionally required to supervise Chrome personally.”

Chrome Was The Unstable Roommate In My Linux Automation Stack

I honestly thought the script was broken at first.

That’s the embarrassing part.

I thought maybe:

• my selectors were wrong
• Playwright was clicking too early
• Pinterest changed something again
• Facebook loaded weird
• Dev.to timing shifted

Normal automation stuff.

Then Chrome itself started pixelating.

And that’s when I got the very specific gut-drop feeling of:

“Oh no. This is a REAL problem.”

The Machine

This entire setup lived on an old HP laptop I turned into a Linux worker box for PostPunk.

Which sounds fun and experimental until the machine becomes responsible for your actual workflow.

The specs were basically:

• 6 GB RAM
• mechanical hard drive
• integrated Radeon graphics
• Chrome
• suffering

The kind of machine where opening Chromium felt less like launching software and more like asking an elderly wizard for one final favor.

And honestly?

I loved the setup anyway.

Because I like building things.

That’s what I do.

Why I Even Built This

I hate manually posting content one platform at a time.

Absolutely hate it.

If I write something, I want it to:

• queue
• schedule
• publish
• move on with life

I do not want to spend every morning manually reposting things across half the internet like a social media intern trapped in a Groundhog Day loop.

So I built PostPunk.

Not because I wanted “startup founder energy.”

Because I literally needed infrastructure.

I can’t afford a marketing team.

So if I want my work to consistently exist online, I have to build the system myself.

That’s the reality.

The writing.
The scheduling.
The posting.
The visibility.

All of it depended on this weird old Linux laptop not emotionally collapsing during browser automation.

Everything Worked While I Was Watching It

That was the trap.

When I manually tested the workers:

• Pinterest posted
• Facebook posted
• Dev.to posted
• selectors worked
• uploads worked
• clicks landed

Everything looked stable.

Then I would let the workers run unattended and suddenly:

• uploads stalled
• inputs got skipped
• pages froze
• rendering glitched
• jobs hung forever
• Chrome started acting possessed

The worst bugs were the inconsistent ones.

Those are the bugs that make you question your sanity because they fail just rarely enough to feel random.

The Fan Noise Became A Warning Sign

Eventually I started recognizing failure patterns from the machine itself.

Not logs.
Not stack traces.

The actual hardware.

If Chrome started flickering during login, whatever workflow I was running was probably doomed.

Sometimes the screen would:

• partially freeze
• pixelate
• glitch out briefly
• make that horrible little Linux system ringing noise

Then recover if I stopped touching anything for a few seconds.

At some point my operational monitoring strategy became:

“if the fan suddenly screams at 2 AM, something is probably wrong.”

Which is not exactly enterprise-grade observability engineering.

Chrome Specifically Hated This Machine

Firefox mostly behaved fine.

Chrome was chaos.

Even opening normal Chrome windows was basically gambling:

• maybe fine
• maybe frozen
• maybe flickering
• maybe halfway into a rendering crisis

I still do not fully understand why.

Maybe GPU weirdness.
Maybe Linux graphics stack nonsense.
Maybe Chromium was hitting rendering paths the laptop hated.

I genuinely don’t know.

At some point Linux troubleshooting stops being engineering and becomes folklore.

Headless And Headed Browsers Are Different In Ways That Matter

This was the biggest lesson.

The workflows behaved differently depending on whether I could physically SEE the browser.

That sounds fake until you experience it.

Headed mode accidentally slowed everything down enough to stabilize parts of the UI.

Headless mode removed that safety padding.

Suddenly Playwright was operating at full speed against:

• flaky rendering
• unstable browser state
• old hardware
• race conditions
• half-finished uploads
• incomplete UI hydration

This innocent-looking line:

await page.click('[data-testid="publish-button"]');

turned out to mean:

“I hope the UI actually exists yet.”

Which are two very different things.

The Most Linux Thing I Did

At one point I started randomly deleting Chrome-related Linux components trying to “clean up” the environment.

I removed things I absolutely did not understand.

X11 stuff.
Chrome shell integrations.
Random Chromium packages.

Eventually the entire machine started pixelating outside the browser too.

That was probably the strongest:

“hardware may actually be dying”
moment.

Ironically, reinstalling the things I broke actually improved stability afterward.

Which feels spiritually correct for Linux somehow.

What Actually Helped

The fixes were less glamorous than I wanted.

Mostly:

• proper waits
• more logging
• screenshots
• Telegram alerts
• headless mode
• disabling GPU paths
• reinstalling dependencies
• accepting that “works once” means nothing

These flags helped a lot:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox'
  ]
});

And yes:

npx playwright install-deps

actually mattered.

Unfortunately.

This Was Never Really About Chrome

The reason I kept fixing it instead of quitting was simple:

I wanted it to work.

Because this machine became the engine behind everything else.

The Pinterest traffic.
The writing.
The visibility.
The projects.

At one point I dropped from around 5k Pinterest followers to around 4.5k during all the automation hiccups.

That stuff matters when you are trying to build things online consistently by yourself.

I’m a builder.
An inventor.
A writer.

And if I want people to actually SEE the things I make, then I also have to become:

• infrastructure engineer
• automation goblin
• sysadmin
• marketing department
• overnight Chrome therapist

That’s just the reality now.

Final Thoughts

I think the funniest part is that the system eventually became stable enough that I stopped obsessively checking it every few minutes.

Honestly, that was probably the real milestone.

Not:

“the automation worked.”

But:

“I no longer felt emotionally responsible for supervising Chromium personally.”

And that’s probably the closest thing browser automation ever gives you to peace.