Four things that broke my job board (and the one I didn’t notice for two months)

Yann Woo — Tue, 20 Oct 2026 02:41:43 +0000

I’ve been building a remote job board Remote Landers, since July. It runs on Next.js, deployed to Cloudflare Workers, and the job data originally lived in Notion.

This isn’t a tutorial. It’s a postmortem: in a little over three months, the site had four serious problems. I’ll go through them in the order they happened. Each one was harder to spot than the last.

1. More jobs, and the site went down

About 15 days after launch, things looked great. Google’s job search had started picking up our listings, and we were ranking well for a few keywords.

Then we hit around 850 live jobs, and the site started crashing. Cloudflare was reporting that we’d exceeded resource limits.

The cause wasn’t complicated. Some pages scanned every job in the database on every request, then picked out the few they needed. With a small table you’d never notice. With a bigger one, each request used more compute than Cloudflare’s free plan allows.

The fix had two parts:

Replace “scan everything” with targeted queries. For example, a job detail page now looks up that one job by the identifier in its URL instead of walking the whole table.
Upgrade to Cloudflare’s paid plan, which raises the per-request compute limit.

This one was found fast, because the site simply wouldn’t load, and it was fixed fast too. But it left something behind: while the site was down, our listings disappeared from Google’s job search.

2. We ran out of free GitHub Actions minutes

Job data is pulled from companies’ hiring systems by scheduled GitHub Actions workflows. What I didn’t know at the start is that a free GitHub account gets 2,000 minutes of run time per month.

I had several workflows running every few minutes. Before the month was over, the quota was gone, every workflow was stopped, and the job data stopped updating.

To get the pipeline running again right away, I switched to a paid plan. Then I cleaned up: I removed the workflows that ran every few minutes but weren’t essential, and kept only the core ingestion jobs.

The lesson: almost every free tool has a ceiling. It usually doesn’t warn you ahead of time. You find out when you hit it.

3. I spent a long time fixing a result

The site was back up, but our listings never came back to Google’s job search.

I assumed the problem was the job data itself, so I started digging into JobPosting structured data, the markup that tells Google “this page is a job.”

I did find a real issue along the way. Many jobs were tagged as open worldwide, but when I sampled them, about one in four had a location restriction written right in the description. I changed the rule: a job is only tagged worldwide if the posting actually says so, and jobs with no location information aren’t submitted with that markup at all.

I was also using Google’s Indexing API to notify Google about new and removed jobs. The default quota is 200 requests per day, and we add and remove far more than 200 jobs a day. One day’s log showed 491 of 701 requests rejected. I requested a higher quota and heard nothing back. I requested it again. Still nothing. I also discovered that more than half of our notifications were going to jobs that had already closed and were being re-sent over and over, so I fixed that too.

All of that got fixed. The listings still didn’t come back.

4. A game showed me the real problem

With JobPosting stuck, I was out of ideas. Around then I was playing a startup simulation game where you build and run a website.

The game reduces running a website to a handful of key metrics. Response time is one of them, and a healthy site in the game sits around 30 ms. There’s no structured data in the game, no API quotas, just a few fundamentals.

It made me realize that running a website should be simpler than I’d made it. If a game picks something as one of its few core metrics, it’s probably one that really matters. And JobPosting, the number I’d been staring at, was only a result.

So I checked my own site’s response time: 1,500 ms. Fifty times the game’s number.

Then I compared it with the crawl data in Google Search Console, and noticed the two moved in opposite directions: the slower the site, the less Google crawled it. Google’s own crawling documentation says the same thing: when a site responds quickly, Googlebot is willing to crawl more of it.

That was the cause. The job data had always lived in Notion. I chose it because it’s easy to edit and you can see everything at a glance. The cost was speed: pages queried Notion at request time, and Notion’s API isn’t fast.

This problem never crashed anything. Pages loaded fine, just slowly, so it went unnoticed for two full months. The CPU crash knocked our listings out of Google’s job search; slow responses kept them from coming back.

I moved the job data out of Notion into a database on Cloudflare, so pages no longer ask Notion anything at request time. Response time dropped from 1,500 ms to around 400 ms.

And then our listings started showing up in Google’s job search again. All the time I’d spent on structured data hadn’t brought them back. Fixing response time did.

What I took away

Looking back at all four, two things stand out.

First, the more serious the problem, the quieter it tends to be. A crash gets noticed immediately. A slow site can go unnoticed for months.

Second, it’s easy to keep fixing the result you can see. JobPosting was a number I checked every day, so I kept working on it. Response time was a number I wasn’t watching, so it never got fixed.

These days I check response time regularly, to make sure it doesn’t quietly creep up again.