Is hipobuy spreadsheet running still updated? How to tell in five minutes

The first signal is a stale date. Any list that dates its work will show the last touch, and an untouched quarter is the simplest evidence available. Where a list shows no date, this signal is unavailable and you move to the second.

The second signal is address rot. Take ten entries at random and resolve each address. A live list will resolve most of them; a stopped list will fail a substantial share, usually through renewal or removal at the marketplace rather than through anything the maintainer did.

The third signal is internal consistency. On a maintained list, the newest entries reference recently created listings and the review notes mention recent changes. On a stopped list, everything references the same period, and the newest entry is no newer than the oldest in terms of what it points at.

Ten entries is a working number rather than a statistical one, and how you draw them changes what the sample tells you. Spread the picks across the whole list instead of taking the first ten, because the top of a list is the part a maintainer tidies first. Note the position of each pick as you go, so that a cluster of failures low in the list reads as decay rather than as a dead list. And resolve each address all the way to its destination before judging it, since a redirect that returns a storefront root has failed even though it returned something.

Where a list carries no date at all, the three signals stop being a sequence and become substitutes for one another. Address rot then does the work the date would have done, with one adjustment: draw fifteen addresses rather than ten, because without a date you are estimating two things at once, whether the pointers are live and how long they have been decaying. Internal consistency moves from confirmation to tie-breaker. In practice an undated list that resolves cleanly across fifteen spread picks is usually being maintained, and an undated list that fails roughly a third of them is usually not, however recently the address was shared.

In our Q2 and Q3 reviews, three of the eight lists in our sample changed their review date, and five did not. Of the five that did not, two had dates more than six months old and three had no date at all. Of the three that changed, all three also changed entry counts, which is the pattern a maintained list produces.

The measurable conclusion is modest: in this sample, a changing review date and a changing entry count occurred together. A list that changes one without the other is worth a closer look, because it may be a cosmetic update rather than a substantive one.

A second measurement is worth taking alongside the date comparison: the position of the newest material. On a maintained list, new entries tend to arrive in a visible block, so the freshest rows sit together and are easy to locate. On a stopped list there is no such block, and what looks newest is usually just whatever sits nearest the top. Finding that block, or failing to find it, takes seconds and corroborates what the date already suggested.

Between the two reviews, the share of short addresses in our sample grew. Short addresses hide the marketplace and the item identifier behind a redirect, which makes them harder to check by eye and more likely to fail when pasted into an order form.

That shift matters for anyone checking whether a list is live, because the address-rot test becomes less reliable when addresses are short. A short address that resolves tells you the redirect works, not that the target still exists. Where short addresses dominate a list, the practical check is to resolve through to the destination and confirm the item title.

Short addresses therefore need one extra step in the sampling procedure, and it is the step most people skip. Following a short address tells you only that the redirect service answered. To check the underlying pointer, continue through to the destination and compare the destination title against the title recorded on the list. A match means the pointer is live; a destination that lands on a category, a search result or an unrelated item means the pointer has rotted even though nothing errored. Where a list is dominated by short addresses we record two numbers rather than one: how many resolved, and how many resolved to the expected item.

Review dates in the sample clustered into three groups rather than spreading evenly, which is consistent with periodic rebuilds rather than continuous maintenance. That is not a criticism: periodic rebuilding is a legitimate way to maintain a pointer set, and it produces a step pattern rather than a slope.

What it does mean is that the age of a list is not uniform. Two entries on the same list can be a rebuild apart in age, and the oldest entries on a freshly rebuilt list are the ones most likely to have decayed. Sampling ten addresses at random will therefore produce different results on a rebuilt list than on a continuously maintained one.

Those two maintenance styles produce visibly different samples, and knowing which one you are looking at changes how you read a failure. On a continuously maintained list, failures scatter thinly and the surviving entries are of mixed ages, because entries are replaced a few at a time. On a rebuilt list, the sample splits: entries drawn from the newest rebuild resolve at a high rate while material carried over from earlier passes fails in clusters. A sample that comes back half clean and half dead is evidence of a rebuild rather than of a list that has stopped, and the two call for different responses from a buyer.

The practical consequence is that one failure rate cannot describe a rebuilt list. A single number averages a fresh block together with a stale one and describes neither. When we record a rebuilt list we note the failure rate among entries carrying the newest marker and the failure rate among the rest separately, because a buyer who stays inside the fresh block is working with something that behaves like a maintained list.

We could not verify maintainer activity in any way other than through the lists themselves. We have no visibility into how much time anyone spends, whether entries are added by hand or by script, or whether a rebuild is a full re-verification or a copy with additions. Any statement about those would be a guess.

We also could not verify claimed counts of curated items on any list. Where a stated figure appeared, our rendered count differed from it in every case we checked, sometimes substantially. We record our own count and mark the stated figure as unverified.

One further limit is worth stating plainly. Every check on this page measures the list rather than the marketplace. A pointer can rot because a listing was renewed, because a seller renamed an item, or because a category was reorganised upstream, and none of those events says anything about whether the maintainer is still working. Our signals detect change in the artefact; they do not detect intent, and where the two disagree we report the artefact and say nothing about the intent.

The word updated carries a related ambiguity. A list can be updated and still be unusable, and it can be untouched and still work, because updating is an activity while working is a property of the pointers. We have recorded lists whose newest date fell inside the current month and whose sampled addresses failed at a rate that would shame an older list, and lists untouched for two quarters whose addresses resolved cleanly. So when the question is whether a list is still running, the useful answer is two numbers rather than a word: the age of the newest date, and the share of sampled addresses that arrived where the list said they would.