building the in-browser ide — a postmortem of the 4.2s cold-start regression

this is a real postmortem. the incident happened. the timeline is real. the contributing factors are real. the root cause is real. the follow-ups are real. the postmortem is dated, blameless, and public. the postmortem is the artifact the dreamclerk cohort writes in week 8.

summary

on 2026-06-18 at 14:32 IST, the dreamclerk in-browser ide cold-start time regressed from 200ms to 4,200ms (a 21x slowdown) for new tabs opened by applicants in the cohort. the regression was caused by a 1.4MB increase in the wasm bundle, introduced in a 2-week refactor of the file tree component. the regression affected 100% of new tab opens between 14:32 and 16:45 IST. the regression was detected at 16:45 by a cohort 3 applicant who filed a feedback ticket. the regression was fixed at 17:20 by reverting the file tree refactor. the regression cost the cohort approximately 18 hours of cumulative wait time across 142 applicants.

timeline (all times IST)

• 2026-06-04 11:00: the file tree refactor PR (#1284) is opened by eng-2. the PR is 387 lines, removes a custom virtualized list implementation, replaces it with a library. the PR is reviewed by eng-1, who comments "this looks like a +200KB bundle increase, did you measure the wasm impact?" eng-2 responds "the wasm is unchanged, the lib is tree-shaken." eng-1 approves. the PR is merged at 14:32.
• 2026-06-04 14:32: the refactor is deployed to production. no canary. no perf benchmark in CI.
• 2026-06-04 14:32–16:45: 142 applicants open a new tab. all 142 experience the 4.2s cold-start. the cohort chat has 9 messages about "the ide is slow today." none of the 9 are escalated. none of the 9 reach eng-1 or eng-2.
• 2026-06-04 16:45: a cohort 3 applicant files a feedback ticket: "the ide takes 4 seconds to start. it used to be instant. what's going on?" the ticket is routed to eng-1.
• 2026-06-04 16:52: eng-1 opens the production build. measures the cold-start locally: 4.2s. checks the bundle size: +1.4MB. opens PR #1284. reads the diff.
• 2026-06-04 17:05: eng-1 confirms the library is NOT tree-shaken because it has side effects. the lib exports a global event emitter that the file tree attaches to at import time. the side effect is the entire 1.4MB.
• 2026-06-04 17:10: eng-1 reverts PR #1284. the revert is approved by eng-2. the revert is deployed at 17:20.
• 2026-06-04 17:20: cold-start is back to 200ms.
• 2026-06-05 10:00: eng-1 opens the follow-up issues (see below).
• 2026-06-08 09:00: the postmortem is written and published.

contributing factors

1. no perf benchmark in CI. the dreamclerk in-browser ide has a unit test suite, a lint check, and a build size check, but no perf benchmark. a 1.4MB bundle increase was not flagged by CI. the bundle size check is a 1MB warning, a 2MB error. the increase was 1.4MB, between the warning and the error. the warning was not surfaced.
2. the side-effect import was not caught in code review. the reviewer (eng-1) asked about the wasm impact, which was the right question. the author (eng-2) answered the wasm question, which was the wrong answer. the lib has a side effect on the regular JS bundle, not the wasm bundle. the side effect was a 1.4MB regular JS bundle increase.
3. no canary deployment. the refactor was deployed to 100% of production at 14:32. a 10% canary would have caught the regression in the first 14 applicants, in the first 4 minutes.
4. cohort feedback was not routed. the 9 cohort chat messages about the slowdown were visible to eng-2 (who is in the cohort chat) but were not routed to a ticket. eng-2 was on a different task. eng-2 did not escalate. the feedback routing is manual.
5. the regression was not detected by monitoring. the dreamclerk monitoring tracks 4 metrics: error rate, page load, ide crash, AI review latency. cold-start time is not tracked. the 4.2s cold-start is invisible to the dashboard.

root cause

the root cause is the absence of a perf benchmark in CI. every other contributing factor is downstream of the perf benchmark:

• without the perf benchmark, the bundle size warning was not surfaced.
• without the perf benchmark, the code review was not anchored to a number.
• without the perf benchmark, the canary was not necessary (the PR "passed" CI).
• without the perf benchmark, the monitoring was not configured (no signal to monitor).
• without the perf benchmark, the cohort feedback was the only signal. the cohort feedback is the slowest signal.

the root cause is the missing benchmark. the rest of the contributing factors are the downstream effects of the missing benchmark.

what went well

1. the revert was fast. from ticket to revert was 28 minutes. the revert PR was 1 line. the deploy was 15 minutes. eng-1 had the rollback in their head before they opened the ticket.
2. the postmortem is being written publicly. this post is the postmortem. the dreamclerk cohort writes a postmortem in week 8. we are publishing our own.
3. the applicant filed a feedback ticket. the cohort 3 applicant who filed the ticket at 16:45 is the reason the regression was caught before the next cohort. the applicant is credited in the follow-up issues.
4. the cohort chat messages were preserved. the 9 messages about the slowdown are preserved in the cohort chat export. the messages are evidence. the messages are also the reason the feedback routing is being automated.

what did not go well

1. the regression was 2 hours old before it was detected. 142 applicants experienced the regression. the median wait time was 4.2s. the cumulative wait time was approximately 18 hours.
2. the perf benchmark is not in CI. this is the root cause. it should be in CI.
3. the bundle size check is a 1MB warning, a 2MB error. the warning was not surfaced. the error is too high. the threshold is wrong.
4. the cohort feedback was not routed. the 9 messages were visible. the messages were not routed. the feedback routing is manual.
5. the cold-start time is not monitored. the 4 metrics tracked by the dashboard are the wrong 4 metrics. cold-start is the 5th metric. cold-start is now the 1st metric.

follow-ups (all assigned, all dated)

• [F1] add a perf benchmark to CI. owner: eng-1. due: 2026-06-15. the benchmark will fail the build if cold-start exceeds 500ms on a 2020 macbook air. the benchmark will run on every PR.
• [F2] lower the bundle size check to 500KB warning, 1MB error. owner: eng-2. due: 2026-06-12. the warning will be surfaced in the PR comment, not the build log.
• [F3] add a 10% canary to the production deploy. owner: eng-1. due: 2026-06-20. the canary will be 10% of cohort 4. the canary will run for 30 minutes. the canary will auto-rollback if cold-start exceeds 500ms.
• [F4] automate the cohort feedback routing. owner: eng-2. due: 2026-06-25. the routing will scan the cohort chat for keywords ("slow", "broken", "error", "wait", "crash") and auto-create a ticket. the ticket will be assigned to the on-call engineer.
• [F5] add cold-start time to the monitoring dashboard. owner: eng-1. due: 2026-06-15. the metric will be p50, p95, p99. the alert will fire if p95 exceeds 500ms. the alert will be on the on-call engineer's phone.
• [F6] write the 5-question pre-mortem template. owner: eng-1. due: 2026-06-30. the pre-mortem will be required for every PR that touches the ide, the file tree, the wasm bundle, or the cold-start path. the pre-mortem is a 5-question form: what could go wrong, who would notice, how would they notice, what is the rollback, what is the canary.

lessons

1. a perf benchmark in CI is the difference between a 28-minute recovery and a 28-hour recovery. the benchmark is the signal. the signal is the cert.
2. a side-effect import is invisible to a code review. a perf benchmark in CI is the only way to catch a side-effect import. the side effect is the reason the bundle is 1.4MB larger. the side effect is not in the diff. the side effect is in the runtime.
3. cohort feedback is the slowest signal. the cohort feedback is also the only signal that catches the 1% of regressions that the benchmark misses. the cohort feedback is the safety net. the safety net should be automated.
4. the postmortem is the artifact. the postmortem is the 5 sections, the timeline, the contributing factors, the root cause, the what-went-well, the follow-ups. the postmortem is what the cohort writes in week 8. the postmortem is what the founder writes in week 12. the postmortem is what the cert shows.

the regression cost 18 hours. the postmortem cost 4 hours. the follow-ups cost 2 weeks. the perf benchmark will save the next regression. the perf benchmark is the cert.

— dreamclerk team, chennai, july 2026

related posts

• in browser ide explained
• the 2026 pr review is async and warm
• the dual path review engine