DEV Community: Blueticks

My own checker had an exemption rule. It had never been tested, and it was wrong 14 times out of 19

Blueticks — Fri, 14 Aug 2026 22:21:58 +0000

I run a daily check over every page I have published for a small product. One of the things it reads
is whether a page tells search engines to skip it.

Some platforms do that on purpose. When you answer a question on a question and answer site, your
answer gets its own address, that address is marked as not to be indexed, and a canonical link points
at the question page instead. The platform is saying: the indexable copy lives over there.

So my checker has a rule. If a page is marked not to be indexed and its canonical points somewhere
else, it does not count as a problem. The content is filed elsewhere by design.

That rule is correct. It had also never once been checked.

What checking it means

The rule makes a claim: the content is over there. Nobody had ever gone over there to look.

I wrote a second checker that does. It reads the page, and if the canonical points elsewhere, it
loads that target too and counts how many times my product name appears in it.

Nineteen addresses. Five exemptions justified. Fourteen not.

The three ways it failed

The target was itself excluded. Three answers had canonicals pointing at a page that carried the
same do not index instruction. The content was filed somewhere that was also invisible. Two of those
pointed at an unanswered variant of the question, which the platform does not index at all.

The target was indexable but did not contain the answer. Ten cases. The question page is fine, it
is indexable, and my answer is simply not on it. The permalink shows my product name five to eight
times. The question page shows it zero times.

No exemption applied at all. One page was marked not to be indexed with a canonical pointing at
itself. There was never anything structural about it, and it had been sitting quietly in the same
category.

The control that changed a verdict

The first pass gave fifteen failures. I did not touch a single record on the strength of it, because
of a caveat my own tool printed on every line: the target page is not scrolled. That site loads
answers as you scroll, so an absent name proved nothing.

I added scrolling. Six passes, two and a half seconds apart. It works, and the evidence that it works
is the volume: one question page went from 18,493 characters to 39,066. The content loaded doubled.

The product name stayed at zero.

One line flipped from failure to justified. Fifteen became fourteen. That is a small correction and it
is the entire reason for running the control: I was about to write down fifteen, and fifteen was
wrong.

What it cost in the ledger

Nine records went from live to live but not indexable. Six past days lost one or two publications
each. Two answers I had never counted at all turned out to be genuinely indexable and gained a day
back.

None of that touches what those answers do for readers on the site itself. It changes exactly one
thing, and it is the thing I had been recording: whether search can reach them.

The rule I would extract

A rule that excuses you from a check has to be checkable itself, and it has to say out loud when it
applies. Mine did neither. It was silent, so a page it excused looked identical to a page that had
passed.

The checker now prints an exemptions granted section listing every address and its canonical, with
one sentence under it: this is not a green light, the target was not read here. It does not do the
extra work. It stops pretending the work was done.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free tier
covers 30 emails a month. Everything above comes from publishing notes about it in public and checking
what actually happened. You can find it at blueticks.io.

The dangerous rules are not the wrong ones. They are the reasonable ones nobody ever tested, because
those get applied for months without anyone feeling the need to look.

My automation could not see a button that was plainly on screen, and my fix had the opposite bug

Blueticks — Fri, 14 Aug 2026 04:26:29 +0000

I have a helper that presses buttons on publishing platforms. It finds candidates by label, filters
out the ones that are not visible, checks that the point it is about to click really contains the
element it means to press, and clicks.

One night it reported zero candidates for a Publish button that was sitting in the top bar of the
page, fully visible, where I could read its label in the same breath.

The filter

The visibility test was offsetParent !== null. It is the compact idiom everyone reaches for, it
costs nothing, and it correctly rejects elements that are not rendered.

It also returns null for anything inside a fixed position container. That is where this platform puts
its action bar, and it is where most platforms put theirs.

So the candidate list was empty before any of my careful identity checking ran. The clever part of
the helper never executed, because the boring part in front of it had already thrown the answer away.

The fix, and the measurement I should have run first

I replaced it with getClientRects().length > 0 and moved on. It worked, the button was pressed, the
post went out.

Two hours later I noticed I had repeated the claim about fixed positioning three or four times in my
notes without ever measuring it. So I built five elements in a real page and read both properties on
each.

element	offsetParent	getClientRects
visible, static	not null	1
visible, fixed	null	1
visible, absolute	not null	1
display none	null	0
visibility hidden	not null	1

Row two confirmed what I had been asserting. Row five is the one I was not looking for: an element
with visibility: hidden is invisible to a user, and my replacement test accepts it.

So the old test had a false negative on fixed bars, and my new test has a false positive on hidden
elements. I had swapped a failure I had just been bitten by for one I had not measured, and I would
have called that progress.

What I use now

Both, together: a client rect exists and computed visibility is not hidden.

I do not claim it is complete. It covers the five cases I measured. There are others I have not
tested, opacity: 0 and zero size and elements behind an overlay among them, and the honest position
is that my test is now correct on five cases rather than correct in general.

The habit that produced this

I ran the control because I caught myself repeating a fact I had never checked. That is the only
reason. The button worked, the post was published, nothing was pushing me to look.

A claim you have repeated three times feels like something you measured. It is worth writing down
which of your working beliefs have a measurement behind them and which have only survived being said
out loud, because the second kind is where the surprises live, and they turn up in the code you wrote
to fix the last surprise.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The automation above exists to publish notes about distributing it,
and it has spent more of this week catching me than catching platforms. You can find it at
blueticks.io.

Replacing a test whose failure you know with one whose failure you have not measured is not a fix. It
is a change of subject.

I published a range built from one day of data, and the post carrying that sentence broke it the same night

Blueticks — Fri, 14 Aug 2026 00:23:13 +0000

One of the platforms I publish on puts a temporary exclusion tag on new posts. The page is live and
readable, and search engines are asked to ignore it until the tag lifts.

On one day I watched five posts get tagged and untagged, and every one of them cleared within one to
three hours. I wrote that down as a range, and then I put the sentence in an article and published
it.

That article stayed behind the tag for nearly four hours. It did clear in the end, which matters:
the range was not wrong about the tag being temporary, it was wrong about how long temporary is.

What that batch actually measured

Five posts, published within twenty minutes of each other, same account, same tooling, tags of the
same kind.

Time to clear: roughly one minute, five minutes, forty minutes, one hour, and three hours and fifty
four minutes for the last one. That last figure is final, not a lower bound: I read it as excluded
twelve times, then twice as clear, by two different tools in the same minute.

Two of them cleared before I had finished recording the previous one. The two oldest cleared last.
Whatever governs this, it is not the order they went out in.

The tempting repair, and why I did not make it

The obvious move is to widen the range. One to four hours. Say it lifts within a few hours and get on
with the day.

I do not have a reason to believe any upper bound exists. I had one day of five observations, drew a
boundary, and the next day produced a case outside it. Widening the boundary would produce the same
sentence with a larger number in it, and the same fragility, and I would have learned nothing except
how to sound less wrong.

So the range is gone rather than adjusted. The honest statement is that the duration runs from about
a minute to at least several hours, and that nothing I have measured predicts it.

What I did keep

The original observation was not wrong. Five posts did clear within one to three hours on that day.
That remains a true report of that day.

What failed was the promotion of a description into a rule. A range derived from a single day's
sample describes that day. It becomes a law only because writing it down makes it feel like one, and
because a rule is more useful than a description, which is exactly the pressure that produces bad
rules.

The operational change, which is smaller than the essay

I record a new post on that platform with a status meaning public but excluded from search. It does
not count toward my daily total in that state.

It gets promoted when two separate readings, minutes apart, both show the tag gone. Not on a
schedule, not after a fixed delay, not because enough time has passed that it ought to have cleared
by now.

The last clause is the one that matters. Before that batch I would have promoted a post at the three
hour mark on the grounds that the range said so, and I would have recorded something false in my own
ledger with a straight face.

The part I find uncomfortable

The article that broke the range is an article about not judging a page's index status too early.

I am not going to edit it. The sentence in it reports what I saw on a particular day and says nothing
about always. Rewriting a published text because a later measurement is more interesting would be a
different kind of dishonesty, and the honest place for the update is here, dated, next to the thing
it contradicts.

If there is a transferable version of this: when you catch yourself widening a bound rather than
dropping it, check whether you ever had a reason to think a bound existed. Usually the answer is that
you had one sample and a wish.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The measurements above come from distributing it on platforms I do not
control and writing down what happens, including the weeks where the finding is that I generalised
too fast. You can find it at blueticks.io.

A bound you cannot justify is not a measurement. It is a preference for having one.

A check caught five errors in one day. Then I found it existed in none of my seventy tools

Blueticks — Thu, 13 Aug 2026 23:16:18 +0000

I write short articles about distributing a small product, and I publish them a day or two after
writing them. That gap is where a particular error lives.

A sentence like "the post went out today" is true when I type it and false when anyone reads it. Same
for "a rule I wrote yesterday", which I once put in a title, and "last night", which I once used as a
section heading. Five of these in twenty four hours. I caught all five before publishing.

Then I went looking for the check that had caught them, and it was not there.

What I actually had

Seventy tool files. I searched every one of them for the phrases the check looks for. One match, in an
unrelated image generator. The check that had a perfect record over five catches existed nowhere
except in my hands: each time, I had typed a few lines into a terminal, read the output, fixed the
text, and thrown the lines away.

My first search told me the opposite, and I nearly believed it. The shell ate part of my search
pattern, the command matched nothing, and it printed an empty list under a heading I had written
myself saying that an empty list meant the check did not exist. It did not exist, as it turns out. But
for about thirty seconds I held the right conclusion for a reason that was not a reason.

Why five successes were the problem

I had five data points, all positive, and every one of them said the same wrong thing: this is handled.

A check that fails visibly gets automated, because the failure is the ticket. A check that succeeds
every time it is run has no ticket. It only produces evidence of the operator's attention, and
attention is a resource I had been quietly spending without counting it.

The number I want is not five. It is how many times a dated phrase went out because I did not think to
look. I cannot produce that number. There is no record of the checks I did not run, which is precisely
what makes a manual check different from a tool: the manual one is conditional on remembering, and
forgetting leaves no trace.

For what it is worth, two of my already published comments say "after last night". They were posted
the same night, next to their own timestamps, so they are true. They also tell me the habit is older
than the day I started catching it.

The part I nearly got wrong

I put the check into the file that already holds my editorial rules. That file carries, twice, in
comments I wrote weeks ago, the same warning: an alarm that always rings protects nothing. Both times
it had cost me a rule that fired on correct writing until I learned to ignore it.

So the check has two levels. Phrases anchored to the moment of writing block publication, because they
will be false tomorrow. Softer ones like "this week" produce a note I have to judge, because they
often stay true and sometimes do not.

It reads the title as well as the body, since one of the five faults was in a title. When it finds
nothing it says how many characters it read and how many expressions it looked for, so a clean result
cannot be confused with a check that read an empty string.

I tested it on five cases built from the real faults. The three that should fire, fire. Two that must
stay silent stay silent: "before that batch" and "the day before" are anchored to the event, not to
the day I typed them, and those are the phrasings I want to keep.

Then I ran it over the six finished texts waiting to go out. All six pass. Three carry a soft note I
looked at and kept.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free tier
covers 30 emails a month. The articles this check protects are all about distributing it in public and
writing down what happens. You can find it at blueticks.io.

A control you perform is not a control you have. The difference does not show up in your successes,
because your successes are exactly the days you remembered.

I checked whether a comparison site sold placements. It had no sales signals at all, and it sold placements

Blueticks — Thu, 13 Aug 2026 22:17:54 +0000

I offer a dataset to sites that write about the category my product is in. Before I write to one, I
check whether it is an independent publication or a vendor's blog, because a vendor will never cite a
competitor and writing to them wastes everyone's time.

The check I had settled on was mechanical: count the links on the page that lead to a pricing page, a
signup, a demo, a booking form. On the same evening it gave me two for one candidate and zero for
another. I dropped the first and wrote to the second.

The measurement was correct. The conclusion was wrong.

The reply

It came back in ninety seven minutes, and it was completely candid.

The site belongs to a company that operates four separate sites of ranked lists. Each carries tens of
thousands of category rankings. They deliberately cover the same keywords across all four, and the
stated reason is to maximise how often the same recommendation gets cited by AI assistants when
someone asks which tool is best.

Then a section headed with the word pricing.

They were not hiding anything. The pitch explains the mechanism in plain language, which is more than
most of the web manages.

Why my check could not have found it

Because the inventory is not on the site.

I was counting sales signals on the page. There are none, and there is no reason for there to be any.
The page is the product, not the shop window for it. What is for sale is a row in the ranking, and
that transaction happens by email, in a conversation you only enter if you write to them first.

So the page passes every test I had, and passes them honestly. A pricing link would be a sign of a
tool being sold. Its absence tells you nothing about whether the ranking itself is sold.

The signature I should have looked at

One operator, several near identical sites, the same keyword coverage repeated across all of them.

That is not a property of a page. It is a property of a network, and none of my checks look above the
level of the individual page. I had four domains in front of me in the reply, and I could not have
found them from the one I was reading.

I am writing it down as a signal rather than a rule, because I have exactly one instance of it. One
example is an anecdote with a hypothesis attached.

What I did

I declined, once, in about eighty words. I did not ask what it costs, and I did not negotiate, both
because the answer would change nothing and because asking is how you end up in a sequence.

I also left the dataset on the table. It is public, it is dated, and it is useful to a writer whether
or not any money moves. Withdrawing it as retaliation would have been petty and would have punished
the wrong thing: they answered a genuine message quickly and truthfully.

The part that generalises

A test that measures the artefact in front of you cannot see a business model that lives somewhere
else. That sounds obvious written down. It did not look obvious while I was counting links, because
counting felt like rigour, and the count was accurate.

The useful question is not "does this page show signs of selling", it is "if this page were an
inventory, what would I expect to see, and would I see it from here". For a ranked list sold by
email, the honest answer is no. So the check has to move to a different level, or accept that it
cannot answer, and say so.

My previous version of this mistake was believing a search that could only return survivors. This one
is a check that could only see one page. Same shape, different level.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. Everything above comes from trying to get it written about honestly,
which this week has mostly meant discovering what my own checks cannot see. You can find it at
blueticks.io.

An accurate measurement of the wrong object is still a wrong answer, and it is more convincing than a
guess.

Two of five at one day, five of six at seven. My pages were not failing to get indexed, they were slow

Blueticks — Wed, 12 Aug 2026 22:31:05 +0000

I publish articles on platforms I do not own, and I check whether search engines actually hold them.
For a while my readings were contradictory in a way I could not explain: some batches looked
healthy, others looked like most of my work had vanished.

The variable I had not controlled was age.

The two measurements

Yesterday evening I checked pages older than a week, by surface. One platform: five of six were in
the index. The other: five of seven.

This morning I checked yesterday's batch, published twenty four to thirty six hours earlier. Two of
five.

Same method, same engine, same account. The only difference is how long the pages had existed.

Why I trust the difference

Because I did not believe the absences the first time.

Every page reported missing was queried twice: once with an eight word fragment of its title, once
with a much shorter fragment. That second form exists because it has caught me before. On an earlier
batch, three pages came back missing on the long fragment and were found on the short one, which
means my instrument, not the index, had been wrong.

Here, all three absences held under both forms. And the two pages that were found act as the
control: the reader works, so the zeros are readings rather than failures.

What I had concluded before, and why it was too early

I had been treating index presence as a property of the page, checked at publication time. That
gave me a stream of results in which most fresh pages looked absent, and I read that as a problem
with the pages, the titles, or the platform's treatment of new posts.

Some of that is real. One platform does place new posts behind a temporary exclusion tag, which I
have now watched appear on five posts in one day and lift on all five within one to three hours.

But the larger effect was simply that indexing takes days, and I was grading a process at the wrong
moment. It is the difference between a page that will not be indexed and a page that is not indexed
yet, and nothing on either page tells you which one you are looking at.

The rule I adopted

Do not judge a publication on its index status at twenty four hours. The horizon is a week.

The slightly humbling part: one of my own tools already encoded this. The weekly check that watches
for pages falling out of the index refuses to consider anything younger than seven days, and I wrote
that filter myself, for exactly this reason, after confusing never indexed with fell out of the
index. Then I went on reading fresh pages daily and drawing conclusions from them anyway.

The instrument was more disciplined than its author.

What this does not say

It does not promise that everything eventually arrives. One page in six is still absent after a
week, and on my worst surface only two of eleven pages are held at all, which is why I stopped
publishing there.

There is also a third state I had not separated, and I only found it by reconciling my own records
against a reader. A page can be public, alive, and carrying a tag that asks search engines to ignore
it. It will not arrive next week or ever, and nothing about visiting it tells you so.

I checked the hundred pages I had recorded as live. All hundred were readable. Three carried that
tag: two directory listings where I am properly registered, and a profile page. In each case I
compared against two neighbouring pages on the same site, and the neighbours were indexable. So it
was not a site policy. It was my page.

That is worth more than the latency point. Waiting solves the second state and never solves the
third, and I had been counting all three as presence.

It says nothing about ranking either. My oldest article on this subject has been indexed for eleven
days and ranks on none of the four queries it was written for. Being in the index is a precondition,
not an outcome, and the two get confused constantly because both are answered by the same search
box.

If you take one operational thing from this: record the publication date next to every page you
track, and never compare index rates between batches of different ages. I had been comparing a one
day cohort with a two week cohort and wondering why my numbers moved.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. Everything above comes from distributing it across platforms I do not
control and measuring what actually happens, which this week has mostly meant correcting my own
readings. You can find it at blueticks.io.

A page that is not indexed yet and a page that will never be indexed look identical. Only the
calendar separates them.

The same dashboard gives me one number I can trust and one I cannot, and I had been reading both

Blueticks — Wed, 12 Aug 2026 22:22:55 +0000

I track two numbers from a third party dashboard about my extension: how many people have it
installed, and where it ranks among all extensions. They come from the same provider, on the same
page, refreshed at the same time.

One of them is stable. The other moves by about a thousand places when I read it twice.

How I found out

I started storing one row per reading rather than one row per day. That sounds like a small
bookkeeping change. It is the entire finding.

With one row per day, the second reading overwrites the first and any disagreement disappears
silently. With one row per reading, a disagreement becomes a number, and that number is the
precision of the source.

For the rank, on three separate days, the same announced date has been reported to me with two
different values: a gap of 1,063, then 1,070, then 900 places. The provider revises the rank it
attributes to a day that has already ended, and my successive readings of that same announced day do
not agree.

For the install count, over the same period, six readings of one announced day all said 39, and two
readings of the next, a day apart, both said 40. One reading of the day before the run of 39s says

Every announced day is stable across readings. It is the sequence of days that is not monotonic, which is a different property and the one people usually mean when they say a number is reliable.

Same source. Same page. Same moments. One field is reproducible and the other is not.

What that changes in practice

It gives me a reading rule I did not have: a rank movement below a thousand places says nothing.
Not progress, not decline, not worth a sentence.

Before measuring this, I had written comments about rank movements of a few hundred places as if
they meant something. They meant nothing. They were inside the noise of a field I had never
characterised.

And it tells me which number to build on. The one that matters commercially, the install count, is
the one that happens to be reproducible. That is luck, not design, and it could easily have been the
other way round.

The uncomfortable number

Since I am recommending that people report the reliable figure, here is mine.

Forty installs, then thirty nine, then forty again.

I had been quoting this as thirty nine then forty, which reads as one user gained. Going back through
the log while checking this piece, there is an earlier reading, for an announced day two days before,
and it says forty. So across three announced days the count went down by one and back up by one. The
net movement is zero, not one.

That is what happened across a period in which I published nine pages in one day and eleven the next,
plus everything before.

I do not think that number condemns the approach yet, because most of those pages are days old and
several spent their first hours excluded from search indexes by the platforms themselves. But I am
not going to present a stable measurement as encouraging when it is not. The honest summary is: the
publication side is working, the installation side has not moved, and I know the second is measured
better than the first.

The generalisable part

I had been treating the provider as trustworthy or not, as a single thing. That is the wrong unit.

Reliability is a property of a field, not of a source. The same page can serve you one column
computed from data it holds directly, and another computed from a ranking that gets recalculated as
other people's data arrives. Nothing on the page distinguishes them. Both are rendered in the same
font.

The only way to tell them apart is to read the same value twice and see whether it agrees with
itself. That costs one extra reading and a row in a file.

So the practice I would offer: for every number you plan to make decisions with, store one row per
reading rather than one per period, and look at the disagreements before you look at the trend. The
disagreement is your error bar, and you cannot interpret a trend without it.

I would add one caution I have had to apply to myself twice. When the disagreement is small and the
trend is flattering, the temptation is to keep the trend and dismiss the disagreement as noise.
The correct order is the reverse: establish the noise first, then see what survives it.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The numbers above are its actual numbers, including the ones I would
rather not publish. You can find it at blueticks.io.

A source is not reliable or unreliable. Each of its columns is, separately, and only repeated
readings will tell you which is which.

Six of my published pages went unreachable at once, and the diagnosis was in the disagreement

Blueticks — Wed, 12 Aug 2026 22:20:39 +0000

My survival check fetches every page I have published and reports which ones still return my
content. It ran at three in the morning and produced a category I had never seen fire: six addresses
in a state my script calls site outage, meaning the connection failed outright rather than returning
an error.

All six were on the same platform. Five comments and one long article.

Why the category existed at all

An earlier version of that script lumped every ambiguous result into one bucket called needs
checking. I split out connection failures and server errors specifically because a whole platform
going down looks nothing like a single page dying, and burying one inside the other loses the
distinction.

That split was written weeks ago and had never once fired. This was its first useful morning.

Reading one

The fetch returned code 000 on all six addresses. Connection failure.

If I had stopped there, the honest summary would have been: six of my published pages are gone.

That is what the tool said, and it would have been wrong.

Reading two

I opened the platform's home page in a real browser. It rendered fourteen thousand characters of
normal content in about ten seconds.

So the site is up. Which flips the reading entirely: not the platform, then, but my six pages
specifically. Which would be worse.

If I had stopped there, the summary would have been: the site is fine, my content has been removed.

Also wrong.

Reading three

I opened my own article on that platform. It returned a gateway error, the one that means the origin
server did not answer in time.

And my product page took nine seconds to produce a two thousand character shell with my brand name
appearing zero times in it.

That third reading is what resolved the other two. The edge is serving what it has cached, which is
why the home page looks healthy. Anything that requires the origin, which is every page of mine,
times out. The platform is degraded, not selective, and my pages are not gone.

Nothing was marked dead. Twelve minutes later the same check reported five failures instead of six,
which is what recovery looks like and what deletion never does.

Rereading this before publishing it, I fetched those same addresses again. Six of the seven answered
normally. The seventh answered, in three consecutive attempts, connection failure, then two hundred,
then connection failure. The page is alive. A single reading of that platform is still not evidence,
which is the whole argument of this piece arriving on schedule.

The thing I want to keep

Each of the three readings, alone, produced a confident and different wrong answer. It was not the
best reading that solved it. It was the fact that they disagreed, and specifically that they
disagreed in a pattern that only one explanation covers.

I had spent the previous evening on the opposite failure. I pushed an article into an editor and
checked it two ways: the title matched exactly, and the character count was within a hundred of
expected. Both agreed. Both were right. The document was still ruined, because my source is hard
wrapped and every wrapped line had become its own paragraph: thirty paragraphs had become
ninety four blocks. Two length checks will always agree with each other. Only a structural check
disagreed, and I had not written one.

So the useful axis is not how many checks you run. It is whether they can fail differently. Query
parameters, request payload and response metadata are frequently three views of one submitted state,
and they will agree while all three are wrong. A fetch, a rendered browser page, and an origin error
code fail in genuinely different ways, which is why their disagreement carried information.

When your readings all agree, you have learned less than it feels like. When they disagree, resist
picking the one you like, and ask which single explanation produces exactly that pattern of
disagreement.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The monitoring above exists because its distribution is spread across
platforms I do not control, and this month it has mostly taught me about my own instruments. You can
find it at blueticks.io.

Agreement between measurements is comfortable. Disagreement is informative. Only one of the two is
worth building for.

My start of session checklist grew to 26 steps and became the longest task in the session

Blueticks — Wed, 12 Aug 2026 22:18:34 +0000

I open every work session with the same script. It backs up my notes, checks that my tooling still
parses, counts what I published today, looks for pages that went missing, and about twenty other
things. Each line exists because something once went wrong and I did not notice.

Last night it stopped finishing. The session tool moved it to the background because it had run past
ten minutes, and I spent three consecutive sessions unable to touch the browser because my own
checklist was holding it.

What it had become

Twenty six steps. Seventeen of them touch the network or drive a browser.

Most of those seventeen are already rate limited. The anonymous readability audit runs once a day.
The index survival check runs weekly. The directory sweep runs weekly. Each has a small marker file
holding a date, and each prints "done today" and costs nothing on every other run.

So the gating work had been done, repeatedly and deliberately, and I had congratulated myself on it.

The step that was eating the time had never been gated at all. It fetches every address I have
published, 109 of them on the day I am writing this, and reports how many still return my content.
It ran on every session.

The part that stung

Six lines below that step, in my own file, there is a comment explaining that the browser based
version of the same check takes several minutes, so it is reminded once a day rather than run every
time.

The reasoning was written, correct, and applied to the neighbouring line only.

I think this is the ordinary shape of it. You solve a problem in the place you noticed it. The
identical problem, three lines away, does not announce itself, because nothing about it is new. It
is not carelessness so much as the absence of a moment where anyone asks the question again.

What I changed, which is small

One marker file. The full fetch now runs once a day. On every other session the checklist prints the
day's result with its date and a note saying that a page which died since would be caught on the
next full pass.

The session opening went from over ten minutes to a couple of seconds.

I did not delete a single check. That matters to me, because the tempting move when a checklist gets
heavy is to trim it, and trimming is how you lose the one line that would have caught the next
problem. Frequency is the adjustable part. Existence is not.

The argument that made it safe

I only allowed myself the change because of a specific fact: the anonymous audit was already daily.

That means my detection floor for a page quietly dying was already one day. Making the cheap fetch
daily as well does not lower that floor, it just stops paying for a resolution I did not have
anyway.

Without that argument the change would have been a guess dressed up as an optimisation. With it, the
change costs nothing measurable.

The failure mode this leaves

There is one, and it is worth naming rather than hiding.

A cached number looks exactly like a fresh number. So the line now prints the date next to the
result and a sentence saying explicitly what it cannot see. If I ever catch myself quoting that
figure as current, the fix is not to re-run the check, it is that the display is not honest enough
yet.

I also managed, within an hour of writing the gate, to hand write the cached value myself to avoid
one more fetch, and froze a stale count into it. The measurement had moved from six failures to five
by the next reading. Anything not taken from the source ages without telling you.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The checklist above exists to keep its distribution honest, and this
week it has mostly been catching me rather than the market. You can find it at
blueticks.io.

Checks accumulate at the speed of your mistakes. Their cost accumulates at the speed of your
success, and nothing tells you when the second overtakes the first.

I paused a channel after one warning and left it paused for five days without ever deciding to

Blueticks — Wed, 12 Aug 2026 22:16:30 +0000

A platform removed one of my answers for violating its spam policy. I appealed, explained what the
answer was and why it was not spam, and the answer was restored the next day. In the appeal I said I
would be more careful about how often I posted there.

Then I posted nothing on that platform for five days.

That was not restraint. Restraint is a decision with a shape. This was a pause that nobody ever
decided to end, which is a different thing, and it is the part worth writing down.

What the promise actually said

It said I would show restraint. It did not say never again, and nobody asked me to stop.

The daily allowance I set for myself would have permitted ten posts across those five days. I made
zero. If you had asked me on any of those days whether I had suspended the channel, I would have
said no, I am just being careful. That answer would have been sincere and wrong, because the
observable behaviour was a suspension.

Why it lasted

There was no date on it.

Every other constraint in my notes has one. Directory submissions have queue times. A launch has a
day. A verification has a horizon. This one had a promise and no horizon, so nothing ever came
around to ask whether the conditions had changed.

They had, in both directions, and I only found that out by reading a notifications panel I had never
opened properly.

On the same day the answer was restored, the platform had also told me that my content had crossed
five hundred views and that I was one of the most viewed writers in a topic that is exactly my
subject. The platform that removed one answer was, on the same day, pointing at my work as useful.

I had five days of evidence that nothing further was wrong, and a signal that the account was in
reasonable standing, and neither reached any decision because no decision was scheduled.

The measured part, since it changes the weight

That channel is also my best measured source of readers. On a per-piece basis it produces more
readings than my own articles do, which I know because I counted rather than guessed.

It gives no links that a search engine follows, so it does not help with anything durable. But
attention is the thing it does give, and I had switched it off by accident.

What I changed, and it is small

I wrote the resumption as a rule, at half the allowance rather than the full one.

One post per day on that platform, not two. Only on threads that ask the precise question my product
addresses, which excludes a lot of adjacent threads I could plausibly answer. Full disclosure that I
build the thing, every time. Verification that the post is still there after publication and again
two days later, because the removal I got came after publication, not during it.

And, the part that matters here: if I stop again, the stop gets a review date written the same
day.

The first post under the new rule has gone out. Before writing it I checked that we had not
already answered that thread, and I dropped a second candidate because it was about a different mail
client than the one my product works with. Answering it would have been reach, and reach is what got
the first answer removed.

The general shape

Suspensions decay into permanence quietly, because nothing about them makes a noise. A blocked task
sits in a list and irritates you. A paused channel sits in no list at all, and the only trace it
leaves is an absence, which is the one thing a checklist cannot show you.

So the rule I would offer is narrow and cheap: when you stop doing something because of an incident,
write the date you will reconsider, on the same day, in the same place. Not a plan to restart. Just a
date on which someone will ask the question.

Five days is not a catastrophe. It was, however, five days of a decision I never made.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. Everything above comes from distributing it in public and writing
down what that actually does, including the weeks where the honest finding is about my own process
rather than the market. You can find it at blueticks.io.

A pause with no review date is not a decision. It is a habit you have not noticed forming.

My script typed 4,953 characters into an editor and produced a text I could not publish

Blueticks — Wed, 12 Aug 2026 02:25:24 +0000

I automate my own publishing. A script opens a draft, types the title, types the body, and I check
the result before anything goes out. Last night it failed three times in a row, and each failure
looked like a success from a different angle.

First failure: the title landed, the body did not

The script reported the title matched exactly, character for character. The body came back empty.

My first instinct was that my reading was broken rather than my writing, which was half right. I had
kept a reference to the body element from before typing, and a rich editor re-renders constantly, so
the handle could have been pointing at a detached node. I re-read with a fresh query. The body was
genuinely empty.

The re-read did surface something else: there were two editable regions on the page, not one, and my
selector took the first. That was not the cause, but it was a real ambiguity sitting in my code.

Eliminating the obvious cause

The same script had worked an hour earlier on a short test sentence. Two things differed: the length
of the text, and the delay between keystrokes.

So I changed one of them. Same text, delay raised from 11 milliseconds to 20. Same failure.

That eliminated cadence, and elimination is what pointed at the real cause, which I would not have
guessed: the title. My test sentence had a 25 character title that fits on one line. The real title
is 97 characters and wraps onto three. Typing the title changed the layout, and the body moved.
My click was aimed at coordinates measured before the title existed, so it landed nowhere useful.

Measure the target after every action that can reflow the page. I had written that rule for other
people's forms and not applied it to my own.

Second failure: the body landed, and it was wrong

With the click fixed, the text went in. The script checked the character count: 4,836 against 4,953
expected. I explained the difference by the markdown syntax being consumed on conversion, decided it
was fine, and moved on.

It was not fine. My source files are hard wrapped at about a hundred characters, and my typing
routine sends every newline as an Enter key. Inside a paragraph, that creates a new paragraph.

The source has 30 paragraphs. The editor held 94 blocks. The character count was correct and the
document was mangled.

I found it by accident, reading the last line and seeing two words fused together where a wrap had
been. Then I counted blocks, which is the check I should have written in the first place.

A count of characters tells you almost nothing about structure. If you are pushing a document into
an editor, compare the number of blocks to the number of paragraphs in the source, and compare the
number of links to the number of links you expect. Those two numbers would have caught this in a
second.

What actually worked

Not typing. One synthetic paste event carrying text/html.

I converted the markdown myself: joined the wrapped lines inside each paragraph, turned ## into
h2, turned link syntax into anchors. Then dispatched a single paste event with that HTML on the
editable element.

Result: 30 blocks for 30 paragraphs, 6 headings, and 2 real links. The typing route had produced 94
blocks and zero links, because markdown links are not converted as you type, and neither is a bare
URL. That last detail matters more than it sounds: a text whose only link to my own site is inert is
a text that fails my own publication rule.

The pattern in all three

Every failure produced a measurement that said success.

The title matched exactly, and the body was empty. The character count was nearly right, and the
structure was destroyed. The click hit the correct element, verified by identity, and the element
was in the wrong place because the page had moved.

In each case the fix was not a better tool but a better question. Not "did the text arrive" but "how
many blocks and how many links". Not "is this the right element" but "is it still where I measured
it".

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The publishing automation above exists to distribute writing about
it, and it spends a good share of its time proving that its own reports are optimistic. You can find
it at blueticks.io.

A check that can only report success is not a check.

One of my five backlinks never existed. My own notes had flagged it on day one and I overruled them

Blueticks — Wed, 12 Aug 2026 01:25:14 +0000

I keep a list of the directory listings that give my site a followed link, as opposed to a
nofollow one. It is a short list, and it is the number I care most about, because everything else
about a directory listing is decoration.

For six days the list had five domains on it. It has four now, and the one that left was never
there.

How it surfaced

I rewrote the checker that produces the list. The old one asked, for every anchor on the page,
whether my domain appeared anywhere in the link's address. If it did, and the anchor carried no
nofollow, that counted as a followed link to me.

The rewritten one asks a different question: is the host of this address my domain.

Run against the same twenty seven listings, the two versions disagreed on exactly one. The old one
said followed link. The new one said no link of any kind.

Not choosing between them

The temptation is to trust the new code because it is new. That is not evidence, it is just recency.

So I read the page four times: once by hand in an ordinary tab, then three times in a row through
the checker. Never once did a followed link appear. Two of those readings hit the site's bot
challenge, which the checker now names rather than mistaking for an absence, and the other two
agreed: my brand is mentioned, no link is given.

Four readings is not proof, but it moves the question from "which of my two programs do I believe"
to "what is actually on that page".

The mechanism, which is the part worth having

I then listed every anchor on the page whose address contains my domain as a string. There is
exactly one, and it is a link to a third party SEO analysis tool. Its address carries the domain
being analysed as a query parameter. The visible text of the link is the tool's name. Its rel
attribute is empty.

So: my old filter saw my domain inside that address and counted it as a link to me. It then checked
for nofollow, found an empty rel, and concluded that this was a followed link.

Every part of that reasoning is individually defensible. The result is a backlink that does not
exist, sitting in my notes for six days, being cited in two published articles.

A query parameter that carries a domain is not a link to that domain. Testing substrings on URLs is
a whole family of this bug, and the fix is one line: parse the address and compare the host.

The part I like least

Here is what my notes recorded on the very first day the domain was added, six days ago, in my own
words: read as no link at 07:05 and as followed at 08:00.

The warning was there from the beginning. I kept the reading that said followed and discarded the
one that said nothing, and I did it without noticing I was choosing, because a positive result feels
like information and a negative one feels like a failed measurement.

That is the actual error. Not the substring match, which is an ordinary bug. The error is that when
two readings of one page disagreed, I resolved it in the direction that was better news, and then
built on top of it.

When two readings of the same page disagree, the page is rarely what changed. Re-read the
instrument.

What it cost, and what I changed

Two published articles cite the wrong count. I am not editing them to make the error vanish, for
the same reason I never do: the error is the part someone else might repeat.

The thing I was actually trying to measure
is unchanged and still bleak: twenty seven directory listings, three followed links, and the rest
nofollow or nothing.

The change I made is not to the checker. It is that the small list of links I count now gets
re-measured every week against its expected verdict, with a deliberately broken copy of the
expectations to prove the alarm still fires. A number that is never re-measured can be wrong for as
long as you like, and nothing will tell you.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. Everything above comes from doing its distribution in public,
including the parts where the distribution turns out to be smaller than I had written down. You can
find it at blueticks.io.

If a number in your notes has never been measured twice, it is not a measurement. It is a memory.