Open most listings in this directory and the pricing row says "not verified". That looks like an unfinished product. It is closer to the opposite: it is the one rule the whole thing is built around.
The problem with a plausible number
Hosting prices are unusually hard to state correctly, and unusually easy to state incorrectly in a way nobody notices.
A single European virtual server can be quoted excluding VAT, including VAT, or with VAT varying by the buyer's country. The headline figure may or may not include the traffic allowance, and the traffic allowance may or may not be the thing that ends up on the bill. Introductory rates renew at a different number. Some providers price per month, some per hour with a monthly cap, and the cap is often the cheaper of the two rather than a ceiling on the meter.
Now consider what happens when a directory guesses. A price that is roughly right is indistinguishable from a price that was checked. There is no visual difference between the two, no marker on the page, and no way for a reader to tell which one they are looking at. The wrong number gets quoted in a procurement document, or it decides which of two providers someone picks. By the time anybody notices, the directory has already been trusted.
That is the failure mode this site is designed to avoid, because accurate pricing is the entire product. A directory that is sometimes wrong about price is not a slightly worse version of a directory that is right. It is a different thing.
What has to happen before a number appears
Pricing reaches a listing through one path, and it is deliberately slow.
A crawl fetches the provider's own pricing pages and stores the raw text. A language model reads that text and extracts typed fields: plan names, monthly figures, currency, vCPU, memory, storage, what the free tier actually includes. The extraction is stored as a proposed change, not as data.
Then a person reads the proposal against the source and either approves it or does not. Only approval writes to the listing.
There is no code path from the crawler to a published listing. That is not a policy written in a document somewhere; the function that commits a change is only reachable from the admin panel, and it applies an allowlist of fields rather than whatever the extraction happened to return. An extraction that invented a field cannot write it. An extraction that got the company's home country wrong cannot flip the European filter, because that flag is derived from the country code rather than taken from the payload.
What gets seeded, and what does not
Structural facts are seeded from research: what a provider is, where the company is based, which European countries it runs infrastructure in, whether a free tier exists, and how exposed it is to the US CLOUD Act. Those change rarely and are checkable against public filings and the provider's own documentation.
Prices, plan specifications and free tier limits are not seeded. Where a free tier is described, it says what kind of thing it is rather than how much of it you get. "Free monthly send allowance" is a fact. A specific number of emails is a claim that needs a source.
What this costs
Being honest about this: it costs coverage. A directory that invents plausible figures looks complete on day one. This one looks patchy until the crawls have run and someone has read them.
The trade seems obviously right. A reader who finds an empty pricing row learns something true, which is that we have not checked. A reader who finds a wrong number learns something false and has no way to know it.
If you want to know what a provider charges before its listing has been verified, the listing links straight to their pricing page. That link is the honest answer until the row underneath it is filled in properly.