Lore Week 2: why our checks stopped in seconds, why a correct build can miss a file, and when a bot may merge

Lab, weekly paper. Week of Mon 19 Oct to Sun 25 Oct 2026, Europe/Istanbul. We counted merged pull requests on Sunday 25 Oct at 21:00 Istanbul time, so the last part of Sunday is not in the count.

This week we merged 39 pull requests. A pull request is a proposal to change our code; usually a coding agent opens it for us, and it is checked before it joins the main version. The typical one merged about 30 minutes after it was opened. Most of the work went into a new product we have not announced (25 merges), then AutoReal (6), an internal repository (6) and lorelabs.co (2).

The week also ran out of something we rarely think about: minutes for our automated checks. Of 242 check runs, 21 failed, and 17 of those were not test failures at all. They stopped within 3 to 7 seconds without running a single step, because our account had used its monthly allowance.

We want to teach three ideas the week made clear:

1. A CI minutes budget. What it is, how it is counted, and why a job that does almost nothing can still cost a full minute.

2. Why a deployed bundle can miss a file even when the code is right. A build copies only the files it can see being used. A file loaded another way can be left behind.

3. A low-risk bot merge rule. When a bot may merge a change that another bot wrote, and what keeps that safe.

What it is. CI, continuous integration, is the set of automated checks that run on every proposed change: they read the code, run tests and build the app. On GitHub these checks run on rented machines, and for private repositories each account gets a monthly allowance of machine minutes. GitHub's billing page lists 2,000 minutes a month on the free plan and 3,000 on the Pro and Team plans. The minutes are charged to the owner of the repository, not to whoever triggered the run.

Why it matters. When the allowance is used and no payment is set up, or a spending budget is reached, GitHub stops starting jobs. The checks do not fail because the code is wrong. They fail because they are refused. A red cross that means "no budget" looks just like one that means "broken code" until you open it.

How it works, in simple words. Think of a taxi with a minimum fare. GitHub's pricing page says it rounds the minutes and partial minutes each job uses up to the nearest whole minute. So a job that starts, prints "nothing to do" and exits after 10 seconds costs one full minute. Ten tiny jobs cost ten minutes, even if together they did less than two minutes of work. A job that is skipped by a condition before it starts uses no machine at all, and GitHub reports it as "Success". The cheapest check is the one that is never started when it has nothing to look at.

What happened to us. On 24 and 25 Oct our account ran out of minutes, and 17 of the week's 21 failed runs ended within 3 to 7 seconds with zero steps. This was the second time in two weeks; the first was on 12 Oct. One of our pull requests named the surprise: jobs that only printed a skip line still billed a whole minute each.

The response came in layers. First, the heavy tests in AutoReal now run only when the files they test change, and the slow rendering tests are split into four parts that run side by side. Its main check run had a median of about 6 minutes and a slowest of 12, and the fastest real run after the change took about 4 minutes (wall clock, not billed minutes). Then we opened changes in most of our repositories with one pattern: skip drafts, filter by path, use one job per check instead of several small ones, and let a newer push cancel an older check on the same pull request. A company rule for CI use is written and waiting for approval. We chose a small plan upgrade plus efficiency over a much bigger plan.

What others say. GitHub's own pages give the rules: per job rounding up to the whole minute, a skipped job reports success, and a concurrency setting can cancel a running job in the same group. Independent writers make the cost point more bluntly: ten jobs of 20 seconds bill 10 minutes for 200 seconds of real work, and run logs show real durations while the bill shows rounded ones.

How we compare. We had built many small jobs, which is the pattern rounding punishes most, and we were reading wall clock times as if they were the bill. They are not. Most of the fix is still waiting to be merged, so we cannot yet say how much it saves over a month.

What it is. When we deploy a web app, we do not ship our whole project folder. The build tool makes a smaller package, a bundle, with only the files the app needs at runtime. Next.js has a "standalone" mode that copies exactly those files into one folder that the server runs.

Why it matters. The bundle is what users touch. If it misses a file, the app breaks in production even though every line of code is correct and every test on the full project passed. Tests usually run against the whole folder, where the file is still there.

How it works, in simple words. Packing a suitcase from a list works only if the list is complete. Next.js makes its list by reading the code: it looks for imports and file reads and follows them. Its documentation says plainly that it might fail to include required files in some cases, and gives a setting to add files by hand. A file whose path is built while the app runs can be invisible to that reading.

What happened to us. In AutoReal, approving a post stored a failed draft in production. The cause: the bundle our hosting serves had copied a library's main file but left out a small settings file that the library loads by a path it builds at runtime. The error came before a simpler backup method could take over, because the backup only caught a specific kind of error. The fix adds the missing files to the bundle by hand, lets the backup handle this case, and adds an automated check that runs against the served bundle itself. It merged on 24 Oct at 23:22 Istanbul time.

What others say. Next.js documents both the tracing and its limits. Last week we quoted DORA's advice that the package made by the CI build should be the one used downstream. This incident is that advice in practice.

How we compare. Before this fix, our checks built the app but did not test what is served. Now one check does, but only when the files that shape the bundle change, to save minutes. That trade is reasonable, and it means a new runtime file in an unwatched place could slip through again.

What it is. Merging is the moment a change joins the main version. Until this week only our founder merged. A low-risk merge rule lets a bot merge certain small changes, such as documentation or tooling settings, as long as it is not the bot that wrote them.

Why it matters. Waiting for one person to merge every docs fix slows everything down, and most of those fixes carry no risk to users. But "low risk" has to be a written test, not a feeling, or it grows until it covers things that do matter.

How it works, in simple words. It is the four eyes principle with a checklist. Our rule allows a bot merge only when all six conditions hold:

1. An inspection bot passed the exact version being merged.
2. Every required check is green.
3. The change touches only docs, plans, records or tooling config.
4. It involves no deploy and nothing about money, pricing, legal text, sign in, secrets, CI or anything users see.
5. The author is not the merger.
6. Any merge order the inspector stated is followed.

Product code, design and releases still go through the founder, who can revoke the rule at any time. Where a merge itself triggers a deploy, no bot merges.

What others say. DORA's research, from the 2019 State of DevOps report, finds that change approval works best as peer review during development, supplemented by automation that catches bad changes early, rather than approval by a distant board. GitHub's protected branch settings can require that the latest push be approved by someone other than the person who pushed it, the same idea as our fifth condition.

How we compare. Our rule matches both: review by a party that did not write the change, plus automated checks, with a narrow written scope. One detail slipped. The rule took effect when it merged on 22 Oct, but its record still said "awaiting decision" for two more days. We did not check whether any bot merged under the rule this week.