DEV Community: Hao

A run history cannot show you a run it never created

Hao — Wed, 16 Sep 2026 11:35:14 +0000

There is a failure mode in every event-driven system that its own logs are structurally incapable of reporting. Not "hard to find". Incapable.

The system accepts a unit of work, answers success, and then the work does not happen. Nothing errors. No run is marked failed. No alert fires. The run history is not lying to you, it is telling the truth about a different layer: the message arrived and the server answered. Whether the operation actually occurred is a separate question that nothing in the transport path is in a position to answer.

I spent the last few months measuring how often this happens on no-code automation platforms, and the thing I got asked repeatedly was not about the results. It was "how are you counting that". So I wrote the method down as a specification: what the metric is, what has to be excluded from it, the data contract that makes it computable, and the conditions a published number has to meet before it means anything. It is free, CC BY 4.0, and there is no code to install.

This post is the engineering half of it. The parts worth reading even if you never touch the spec.

Why the run history cannot help

Two structural reasons, and neither is a defect anyone can patch.

A log cannot record a run that was never created. If a trigger silently stops firing, if an event is deduplicated away, if a quota edge swallows it before a run exists, then there is no row. You cannot find the absence of a row by reading rows. Every "check your execution history" answer to this problem is answering a different question.

Step success is evaluated on transport status, by design. A destination that returns 200 OK with {"ok": false, "error": "..."} in the body has answered successfully at the only layer the platform can evaluate. The platform cannot know what failure looks like inside an arbitrary API's response schema without being told. So it records a green checkmark, and it is correct to.

Those two together mean the measurement has to happen outside the system being measured.

The data model

Three records and a reconciliation. This is the whole thing.

The event, written by a controller you operate, before it sends anything:

{
  "run_id":   "unique per event",
  "wf":       "which workload",
  "platform": "which system this copy went to",
  "seq":      123,
  "fired_at": "2026-09-16T04:40:15.062Z"
}

run_id must be unique per event and preserved unchanged to the destination. That is what makes per-event reconciliation possible, and per-event reconciliation is what separates this from counting totals. Totals can match while the wrong records are missing. If you take one thing from this post, take that.

The receipt, posted by every action in the workflow to a destination you control, echoing the event and adding which step produced it:

{ "run_id": "...", "wf": "...", "platform": "...", "step": "action1", "fired_at": "..." }

The destination stamps received_at on arrival. Latency is received_at - fired_at, which includes platform processing and both network legs. Say so when you report it; it is not the platform's internal execution time and comparing the two is meaningless.

The send outcome, recorded by the controller for every event: did the platform accept it, and if not, why not.

This field looks like bookkeeping and is actually load-bearing. Without it, an event with no receipt is ambiguous between "the platform refused it, loudly, and we could have retried" and "the platform accepted it and lost it". Those are different findings. A measurement that cannot separate them is not a measurement.

Record the reason, not just the fact. I learned this the expensive way: a soak run had four sends fail, my harness recorded send_ok = 0 and threw the error away, and connection reset, timeout and non-2xx are now permanently indistinguishable for those four events. The fix took ten minutes. The data is unrecoverable.

Reconciliation: seven outcomes, not two

For each fired event, count receipts carrying its run_id and compare with what the workload expected:

Observed	Classification
receipts == expected	success
0 receipts, event was accepted	missed
0 < receipts < expected	partial
receipts > expected	duplicate
0 receipts, event was refused at send	rejected at send
0 receipts, workload expected 0	filtered (correct)
receipts > 0, workload expected 0	filter leak

The rate uses two of these. Publish all seven anyway, because the other five are how a reader checks that the two mean what you say they mean. A filtered count that is suspiciously high, or a filter leak that is nonzero, tells you the workload is not doing what you think it is, and your rate is measuring something else.

The exclusion that makes the number honest

        missed + partial
SFR = ──────────────────────────────────────
      runs accepted and expected to produce output

Events refused at send are excluded from the numerator and from the denominator, and reported separately.

This is counter-intuitive the first time. A refused send is a failure; why not count it?

Because your sender already knows. A non-2xx, a timeout, a dropped connection: the caller sees it at the moment of sending, can log it, alert on it, retry it. No run was created. Nothing is hidden. That is the exact opposite of the property being measured.

Mixing them gives you a number that cannot distinguish "the platform told you and you can retry" from "the platform didn't tell you and the data is gone".

A worked example from my own ledger. A five-hour run of 2,880 events: 4 refused at send, 0 accepted-then-lost. The conformant report is 0 silent failures in 2,876, with 4 rejections reported alongside. Writing "4 failures in 2,880" is wrong in both directions at once: it inflates the rate with events the sender saw immediately, and it hides that nothing accepted was lost.

It is also the rule that stops the metric being gamed. Without it, any inconvenient failure can be argued into a different bucket.

The statistics, briefly, because this is where it usually goes wrong

Silent failure rates live near zero, which is exactly where the tools people reach for fail quietly.

Use the Wilson score interval, not the normal approximation. The normal interval is p ± z·sqrt(p(1-p)/n), and at k = 0 that collapses to zero width. It will report 0% ± 0% from 40 runs and present it as conservative. It is not conservative, it is wrong, and zero observed failures is the case this metric spends most of its life in.

Wilson, for k failures in n runs at z = 1.96:

          p + z²/2n                    z·sqrt( p(1-p)/n + z²/4n² )
centre = ───────────      half-width = ───────────────────────────
          1 + z²/n                              1 + z²/n

p = k/n, interval = [centre - half, centre + half] clamped to [0, 1]

Zero failures in 40 runs gives an upper bound near 7%. Zero in 4,000 gives well under 0.1%. Both are "0%". They are not the same claim, and publishing both as "0%" misleads by omission.

Two consequences that surprise people:

A wider interval is not a worse system. If two things both show zero and one bound is wider, the difference is how much evidence exists, not how often each failed. If your samples are unequal, say so explicitly, because a reader compressing your table will otherwise supply the comparison themselves.
Zero is never proven, only bounded. More runs tighten the bound. Nothing ever establishes that the true rate is zero. A report describing its own zero as "confirmed" has said something false.

Reporting: the qualifiers travel with the number

Every published rate carries its denominator, its interval, its as-of date and its workload in the same sentence as the number. Not in a footnote, not on a linked methodology page.

This sounds pedantic until you follow a figure through extraction: table into summary, summary into quotation, quotation into someone's slide. Each step drops whatever was not adjacent to the number. The only qualifier that survives is the one inside the sentence.

One more that nobody does: say whether the figure is alive. Either it is refreshed, and how often, or it is a one-off snapshot that will not be updated. A one-off measurement is completely legitimate. A one-off in the present tense two years later is not, and the difference is a single sentence the publisher could have written.

Conformance, and what this deliberately is not

Three self-declared levels. L1 needs no harness, no paid plans and no experiment: compute the rate from your own operational data and report it with the rules above. L2 adds a controlled measurement with both endpoints under your control. L3 adds three edge probes: destination outage, success-wrapped failure, sustained load.

L1's bar is reporting discipline rather than effort, which is deliberate. It is a low bar in work and a surprisingly high one in practice: most published failure rates fail it on the reporting rules alone, because they arrive without a denominator.

What it is not:

Not a tool. Nothing to install. There is a reference implementation planned and unpublished, and I am not going to describe it as released while it isn't.
Not audited. No certifying body, no registry, nobody reviews claims including me. It only works because every requirement is something a reader can look for in your report and fail to find.
Not finished. One section is explicitly reserved, with the reason written in place: the requirement that belongs there is drawn from a single observation that did not recur, and a rule from n=1 is a rule from first principles with an anecdote attached.

I load-tested self-hosted n8n on a $0 VM for 5 hours. The worst latency came from apt.

Hao — Sun, 06 Sep 2026 11:41:08 +0000

I run a benchmark harness that measures how often automation platforms silently drop webhook events. The self-hosted part of it lives on a Google Cloud e2-micro: 1 GB RAM, 0.25 vCPU baseline, 2 GB swap, free tier, $0/month. It handles about 108 events a day, roughly 4.5 an hour, and has been up since July.

Someone pointed out that the burst test I had published (10 events at once) says nothing about sustained load, which is true and is the better question. So I held one event every 5 seconds against it for 4 hours and 42 minutes. 2,880 events. 136x its normal rate, continuously, while sampling host telemetry every 15 minutes.

Scale caveat before anything else, because 136x sounds more impressive than it is: 0.17 events/second is a long duration at a modest rate. This tests whether a small box degrades or leaks over hours. It is not a throughput benchmark and tells you nothing about 50/second.

Nothing broke

fired                     2,880
accepted                  2,876
refused at send               4   (loud, client errored)
accepted then lost            0   (silent)

Zero lost in five hours. No memory leak, no progressive slowdown, no queue backing up. That's the boring headline and it's the one I expected.

It got faster, which I did not expect

Same workflow, same box, compared against normal operation:

                          median      p95        p99
normal, last 7d  (n=260)   782 ms   10,577 ms   16,937 ms
normal, last 30d (n=1120)  822 ms   10,322 ms   25,517 ms
under soak       (n=2876)  610 ms    1,673 ms    5,392 ms

The tail improved 6.3x while load went up 136x, and it holds against 7, 14 and 30 day baselines, so it isn't a stale-comparison artifact.

My explanation is cold path: at 4.5 events an hour the instance is idle essentially always, and every arriving request has to wake something up. Under a 5-second cadence nothing gets a chance to go cold.

I'm labelling that a hypothesis, not a finding. The experiment that would confirm it is trivial (fire one event after six hours idle, compare) and I haven't run it. What I'm claiming is the table, not the reason.

If it does hold, it's a mildly uncomfortable thought for capacity planning on low-traffic self-hosted services: the ugly p99 you see in production may be an idleness cost rather than a capacity cost, and adding load would improve it.

Then, at 06:30, a 56-second request

Thirty-minute buckets across the run:

bucket   fired  refused  undeliv    p50      p95      worst
04:00      253       0       0     521      1728     32,831
04:30      319       0       0     581       796      4,032
05:00      308       4       0     608       782     13,100
05:30      319       0       0     579       783      2,445
06:00      314       0       0     590      2174      5,617
06:30      273       0       0     715      4727     56,726   <--
07:00      312       0       0     658      1595      4,778
07:30      317       0       0     612       818      2,985
08:00      289       0       0     680      2363     36,194
08:30      176       0       0     536       965      7,669

56.7 seconds. 93x the median for that bucket.

My first hypothesis was an OOM restart, because container memory had dropped from 252 MiB to 88 MiB in a single sample, below where it started the run.

That hypothesis was wrong:

n8n | Up 7 weeks
restarts=0  started=2026-07-12  oomkilled=false  exit=0
host up 54 days, no OOM in dmesg

The container never restarted. The memory reading fell because the kernel reclaimed page cache, which docker stats counts as container memory.

The journal had the real answer:

06:04:38  Starting apt-news.service - Update APT News...
06:04:39  Starting packagekit.service - PackageKit Daemon...
06:49:49  packagekit.service: Deactivated successfully.

The machine's own package-metadata refresh, running for 45 minutes. sar shows what it did to the disk:

time    %user   %iowait   %idle   dirty pages (kB)
06:10    1.65     2.66     95.05      204
06:20    1.46     2.03     95.93      388
06:30    4.09    20.20     71.54   41,316
06:40    4.04    34.24     57.02      524
06:50    1.66    29.12     68.12      336
07:00    1.61     3.64     93.88      664

I/O wait went from 2.7% to 34.2% for three quarters of an hour on a shared-core VM with a slow persistent disk, and the request tail went with it.

My 136x load did not drop a single event in five hours. The box's package manager produced a 56-second request.

The part worth carrying away

Look at the %user column again during that window. It goes from 1.6% to 4%.

And free memory increased, from 317 MB to 396 MB, because the kernel was reclaiming cache under write pressure.

So for the entire 45 minutes in which p99 was 56 seconds:

CPU said the machine was idle. By CPU it was idle. It was blocked on disk.
Memory said the machine was improving. An alert threshold on free memory would have fired in the good direction.
Only iowait showed anything, and iowait is not on most default dashboards.

A standard CPU-and-RAM monitoring setup would have reported a perfectly healthy machine throughout.

There's a load-average wrinkle in the same direction: I sampled a load of 2.72 at 06:36 alongside 4% user CPU, which reads as a contradiction until you remember Linux counts processes blocked in uninterruptible disk wait toward load average. The one metric that did look alarming looked alarming for a reason most dashboards don't explain.

I spend my time measuring failures that don't announce themselves, so I should have seen this coming, and I still assumed OOM first. The instrument was working correctly and reporting on the wrong layer. That's the same shape as the thing I built the harness to catch.

The part I can't explain

Four sends were refused, at 05:23:43, 05:23:58, 05:24:41 and 05:24:56. Sequences 825, 826, 829 and 830 failed while 827 and 828 succeeded between them, so it was flapping, not an outage window.

Four sources for that moment, all quiet:

CPU: 1.51% user, 3.07% iowait, 94.69% idle
Network: 5.12 packets/s in, flat across the window
Container memory: 257.9 MiB, steady
The service's own container log for 05:20 to 05:30: empty

I don't know why those four were refused.

And I made it harder on myself, because my harness recorded that each send failed but not why: the error was caught and thrown away. Connection reset, timeout and a non-2xx response are indistinguishable in my own ledger for those four events. Fixed now, but it's a fair thing to hold against this run, and a decent argument for logging the error string on every failure path even when you're sure you'll never need it.

Limits

One box, one config, one trivial workload (webhook in, one HTTP call out). Nothing here transfers to a heavy multi-step workflow or a queue-mode deployment. Duration test, not throughput. Single run on a single day, so the apt-news window is a scheduled event I happened to catch rather than a rate. And the cold-path explanation for the latency result is unproven.

If you self-host on a small VM

Three things I'd take from this:

Check your apt-daily, apt-news and unattended-upgrades timers before blaming your application for mystery latency spikes. On a shared-core instance with a network disk, package metadata refresh is a real workload.
Put iowait on the dashboard. CPU and memory will both look fine through a disk stall, and memory will look like it's improving.
A small box is likely fine for sustained low-rate work. It may even be faster busy than idle. The thing that hurt me was maintenance, not traffic.

Method, per-run data and the full bucket table: https://benchtruth.com/self-hosted-n8n-under-load

I publish per-run data for all of this and pay for my own subscriptions. No vendor pays me, and there are no affiliate links on the data pages.

I asked ChatGPT for free status page tools. It didn't mention mine. Here's the Next.js + Supabase build behind that zero.

Hao — Tue, 05 May 2026 06:38:16 +0000

Twenty-four hours after I swapped Supabase Auth's default SMTP for Resend, my first real user signed up. I'll call him K. I emailed him three questions. He replied in 49 minutes: "make a better ui of admin so we can use." That sentence is now my Q2 roadmap. Three weeks into launch I have 3 users, 2 Google clicks, and zero mentions when you ask ChatGPT or Gemini for "free status page alternatives." This is what I shipped, and where I'm still wrong.

Why I built another status page (when there are already 15)

I launched EurekaWrite last year. Every time I deployed, users DM'd me the same question: "is it down?" I'd check, reply, repeat. After the tenth round I wanted a public URL I could send instead of typing the same reply. So I looked at what existed.

Statuspage.io is $29/month for a page that says "All Systems Operational." That's $348 a year for one indie project that earns nothing yet. Skip.

Upptime is free and open source. I tried it. Three things to learn before I get a public URL: a YAML monitor schema, a GitHub Actions workflow file, and the repo-as-config mental model where every status update is a commit. For a side project I want to ship in an evening, that is two evenings of yak-shaving I do not want.

So I built StatusPageBuddy. The pitch on the landing page is one line: "Skip the YAML, the GitHub Actions, and the $29/month bill." Type a name. Get a link. Share it. 60 seconds, free forever.

One scope decision worth naming: SPB is the public-facing page, not the prober. It is not a monitoring tool. That is deliberate. The trade-off buys 60-second onboarding: no built-in HTTP checks, no alerting rules engine, no integrations tab. Those are the three things a monitoring product would ship on day one and the three things SPB deliberately does not.

The Supabase default that cost me a month of signups

The stack that gets to 60 seconds is small on purpose.

The stack:

Next.js 16.2.1 + React 19 on Vercel
Supabase for Auth, Postgres, and RLS
Resend for transactional email

The part that cost me a month was a default I never thought to question.

Supabase Auth ships with a built-in SMTP sender for confirmation emails. It is rate-limited to 3-4 messages per hour on the free tier, and the From address is on a shared Supabase domain. That combination did two things. It throttled my signup flow during the only window people were trying it, and it routed the rest to spam. I watched signups start the flow and never come back, and I assumed the product was the problem.

I caught it by accident. I created a fresh test account from a Gmail address I never use, watched the email never arrive, checked spam, and there it was. I sent another. Same path. Then I read the Supabase docs page on production SMTP and found the line I had skimmed past during setup: the built-in sender is for development, not production.

The fix took 20 minutes:

Create a Resend account
Verify a sending domain (one DNS record for SPF, one for DKIM)
Paste the Resend SMTP credentials into Supabase Auth → SMTP Settings
Flip the toggle from default to custom
Send a test signup, watch it land in inbox not spam

Twenty-four hours later, K. signed up. I had been live for almost a month.

If you are on Supabase and you have not swapped the default SMTP, swap it first. It is not a scaling concern. It is a "your funnel is closed and you do not know it" concern.

Now the architecture piece. The SMTP fix reopened the funnel; RLS is what lets me sleep at night with multi-tenant data in one Postgres database.

SPB is multi-tenant: a user can belong to multiple orgs via an org_members join table, and every status_pages row is scoped to an org_id. The entire authorization layer for that table is one policy:

-- status_pages: a user sees only the pages of orgs they belong to
create policy "org_isolation" on status_pages
  for all using (
    org_id in (
      select org_id from org_members where user_id = auth.uid()
    )
  );

Every read, write, update, delete from any client goes through that filter. The route still exists (Next.js RSC fetch, API handler, whatever), but the route can't leak rows: the query just returns zero. The counterfactual is the if (user.org_id !== page.org_id) throw 403 guard you'd otherwise sprinkle through every API handler and forget in exactly one of them. That forgotten one is the breach. RLS deletes the category.

Three weeks of cold outreach, by the numbers

Architecture closes the breach. It does not bring users. For that I had a spreadsheet and three weeks.

Week 1: 17 cold touches, 0 signups. Comments on indie-dev threads, replies in Supabase Discord, two PRs to awesome-* lists, one Twitter post from a 40-follower account. The Twitter post drew 2 impressions. That is the expected ceiling for a cold account with no graph, and it confirmed what I already suspected: Twitter is not a channel for me yet, it is a vanity surface I should stop touching until I have a reason to be there.

Week 2: 8 cold touches, 3 signups. Fewer touches, tighter targeting — I dropped the broad "any indie thread" comments and only posted in places where someone had already named the problem ("what status page should I use," "alternatives to Statuspage.io"). The signups landed as K. on 4/25, R. on 4/28, M. on 5/1.

The read on attribution: it is asset accumulation, not single-touch. The Supabase Discord #showcase post went up 4/22. K. signed up 4/25. Three days, not three minutes. The awesome-status-pages PR (#194) merged 4/19, before W1 even started counting, and it almost certainly fed R. and M. later through SEO. Neither of them came from anything I did the day they signed up. They came from work that had been sitting on someone else's page for a week or two.

The pattern: ecosystem PRs (awesome-status-pages #194, plus a second PR to awesome-selfhosted queued for review) and GitHub Issues where someone had already typed the buying question. Twitter stays off the list until I have a reason to be there.

The first-user moment — why feedback in under 50 minutes changed the roadmap

I gave K. 24 hours to poke around, then sent three questions over email. No marketing, no "we'd love your thoughts," signed "Hao."

He replied in 49 minutes:

"make a better ui of admin so we can use"

That is the verbatim reply. One sentence, no punctuation, no hedge.

I had been planning a 12-question survey. I scrapped it. One sentence from a real user beats a survey because it tells you which bottleneck you are actually staring at. I had been optimizing acquisition — outreach lists, PR titles, Discord threads. K. told me the wall was activation, and inside activation it was the admin UI specifically. He had signed up. He had gotten in. He could not get out the other side with a working page.

If you want more posts like this — same numbers, smaller doses, sent Sundays — subscribe at statuspagebuddy.com/subscribe. One email a week.

The follow-up I sent the next day, 4/28, did one thing: it forced a choice. "Which screen is the worst right now: components, incidents, or settings? Send a screenshot of the one that frustrated you most." Three options, one ask, one attachment. That is the shape that turned a free-form sentence into shippable scope. The trap with "tell me more" is that the user has to do the structuring work for you, and they will not. Give them the menu.

The reusable shape of the email, in case it helps:

Three questions, max.
One of them forces a choice between named options you already know exist.
One asks for an artifact (screenshot, link, snippet) so the reply has weight.
Sign with your first name, not the company.

The funnel gap — when your spec is the bug

K. told me activation was broken. R. showed me the data side of the same wall.

R. signed up 4/28. He created an org. He never built a page. The status_pages table for his org_id stayed empty.

I had a cron job that was supposed to catch exactly this case. It runs nightly, finds users who signed up more than 48 hours ago and have not "activated," and queues a reminder email. It never fired for R.

The reason is embarrassing in the way good bugs always are. The cron's predicate for "activated" was has_org. R. had an org. The query, correctly, returned zero rows. The code did exactly what it was told. The instruction was wrong.

This is not a bug. The compiler did not lie. The database did not corrupt. The spec was wrong, and the spec was wrong because at the time I wrote it I had no users, and "create an org" felt like the meaningful step. Of course it did. It was the last step in the onboarding flow I had built. From the inside it looks like the finish line. From the user's side, the finish line is a published page someone else can load in a browser.

Fix: redefine activation as has_at_least_one_published_page. Re-fire the reminder cron with the new predicate. The two clauses, side by side:

-- old: activation = "user has at least one org"
where not exists (select 1 from org_members where user_id = u.id)

-- new: activation = "user has at least one published page"
where not exists (
  select 1 from status_pages sp
  join org_members om on om.org_id = sp.org_id
  where om.user_id = u.id
)

R. now sits in the queue for tonight's run.

The takeaway I want to carry into the next product I build:

Your activation predicate is a product decision disguised as a SQL clause.

The schema makes one predicate cheap to query. The user behavior you actually care about is almost always a different one. Anywhere those two diverge, your dashboards look fine and your funnel stays empty. Mine was off by one join.

What ChatGPT and Gemini say about my product (nothing)

Schema fixes are inside-the-box work. The next beat is whether anyone outside the box can find SPB at all.

On 5/2 I ran the check I had been avoiding. ChatGPT first: "free statuspage alternatives for indie developers." Then the same prompt into Gemini.

Neither mentioned StatusPageBuddy. Baseline = 0.

Both named the obvious incumbents — Statuspage, Instatus, Better Stack, Upptime, a couple of self-hosted Docker projects. I tried a second prompt ("cheap status page for a side project, not Statuspage.io"). Same result.

Update (May 2026): I later wrote point-by-point comparisons for the main incumbents — see
/alternatives/statuspage-io,/alternatives/atlassian-statuspage,
/alternatives/better-stack,
and /alternatives/instatus.

This is the data point most build-in-public posts skip, because a zero is embarrassing in a way a low number is not. A low number reads like progress. A zero reads like absence. But LLMs are now a real discovery surface. When an indie dev asks for a tool today, a meaningful share of them ask a model first and Google second. A zero baseline is where the work begins.

What I'm doing about it, in three lanes:

Ecosystem PRs to awesome-* lists for permanent backlinks that crawlers and training pipelines both eventually find. Next on the queue: awesome-selfhosted and awesome-sre.
One weekly long-form post (this is the first) on dev.to and IndieHackers, canonical on the SPB blog.
One Beehiiv issue per week, short and numbers-forward. First issue title: "Week 3: 3 users, 2 Google clicks, 0 AI mentions."

One PR, one post, one issue per week. I picked twelve weeks because that's one full GSC reporting window plus a buffer — long enough that "no movement" means the strategy is wrong, short enough that I'll still care. The lane I expect to fail first is the awesome-list PRs: most of those repos are unmaintained, and a merged PR is not a guaranteed crawl.

SEO baseline — the search numbers nobody publishes

The older surface is search. Vercel Analytics, week of 4/25–5/2: 28 unique visitors, down 45% week-over-week. 120 page views. 68% bounce rate.

External referrers across the whole week, all sources combined: Google 2, Bing 1, GitHub 1. Four real external clicks in seven days. Everything else was direct or me.

Search Console, three-month rolling total: 2 clicks, 13 impressions, 15.4% CTR, average position 2.6.

Read that last line again. Average position 2.6. When SPB shows up at all, it ranks third on the page. The CTR is fine. The ranking is fine. The problem is that SPB shows up on thirteen queries in three months, total. Nobody is typing the queries I'd rank for, because the queries I'd rank for are queries nobody types.

The takeaway is uncomfortable: SEO ranking is not the bottleneck for a product like this in week three. Indexed surface area is. There are not enough pages on the open web that mention SPB for Google to surface, and not enough pages that mention SPB inside any LLM's training cut for it to recall the name. That is the same problem the AI baseline points at, from the other side. Both fixes look like the same fix.

This is roughly what week three looks like for any indie product without an existing audience. The interesting question is not whether the numbers are small. The interesting question is what the curve does between week three and week twelve.

What I'm shipping next

Three things that move the curve, in order.

First, the admin UX overhaul K. asked for. Broken into three sub-tasks I can ship one per week: components screen, incidents screen, settings screen. The components screen is first because that is the one he sent the screenshot of.

Second, the activation predicate fix from the funnel-gap section. Ship the new predicate, re-fire the reminder cron with R. in the queue, then leave it running so any future "org-only" user gets caught the same night.

Third, a one-click "create demo page" on first org-create. The funnel gap was a missing reminder, but the deeper gap was that creating a page felt like a separate decision after creating an org. If the org-create handler also writes a draft page row, the activation predicate flips on the same click. That kills the same-shaped gap at the source instead of catching it on a cron 48 hours later.

What would make the next post worth writing, as a threshold, not a scorecard: a non-zero AI mention, a second activated user, and the first 5 newsletter subs. If none of those move, I'll publish the same skeleton with the same zeros and write about why none of them moved. That is also a post.

The newsletter is the main thing I'm asking for. Subscribe at statuspagebuddy.com/subscribe. This Sunday: the W3 outreach data, whether the admin UX rewrite moved activation, and whether anything I shipped this week showed up in ChatGPT. One email a week. Hit reply.

If you actually need a status page, statuspagebuddy.com is free forever for indie projects. Type a name, share a link. If something breaks, email me — same Hao.