Operational evidence, built to be checked
This pre-production center demonstrates how VPSEverywhere.com can publish looking-glass endpoints, reproducible benchmarks, measured latency, network identity, component status, incident history, and a deployment changelog. Every number currently shown is fictional example data, visibly labelled and excluded from search indexing until it is replaced and verified.
Key facts
- Current publication state
- Demonstration data — not evidence of a live service
- Looking-glass addresses
- IANA documentation ranges that cannot represent production endpoints
- Benchmark rule
- Publish the command, duration, sample size, median, and test date
- Indexing safeguard
- Noindex and sitemap exclusion until the evidence file is verified
Replace every value before publication
These values are a visual template, not measurements, uptime history, incidents, facilities, carriers, or network claims. Documentation-only IP ranges and private ASNs are used deliberately.
Looking glass
The production version must expose reachable test addresses and a provider-controlled endpoint without granting administrative access.
https://lg.example.invalid192.0.2.102001:db8::10Reproducible commands
- ICMP IPv4
ping -c 5 192.0.2.10 - ICMP IPv6
ping -6 -c 5 2001:db8::10 - Route IPv4
traceroute 192.0.2.10 - Route IPv6
traceroute -6 2001:db8::10
Benchmark results
Example values show the intended comparison layout. Publish medians from repeated tests and keep raw results available.
Published methodology
sysbench cpu --threads=4 --time=60 runfio --name=vpse-4k --rw=randrw --rwmixread=70 --bs=4k --direct=1 --size=4G --numjobs=8 --runtime=60 --time_basediperf3 -c TARGET -P 4 -t 30ping -c 20 TARGETMeasured latency
The example matrix uses fictional median, p95, and packet-loss values. Real measurements must name the source, target, period, and probe method.
| Source | Target | Median | p95 | Packet loss | |
|---|---|---|---|---|---|
| HEL-1 | BUH-1 | 39.4 ms | 44.8 ms | 0.1% | EXAMPLE DATA — NOT VERIFIED |
| HEL-1 | RKV-1 | 42.8 ms | 48.1 ms | 0% | EXAMPLE DATA — NOT VERIFIED |
| HEL-1 | AMS-1 | 24.7 ms | 28.9 ms | 0% | EXAMPLE DATA — NOT VERIFIED |
| HEL-1 | ZRH-1 | 31.8 ms | 36.6 ms | 0.1% | EXAMPLE DATA — NOT VERIFIED |
| BUH-1 | RKV-1 | 67.2 ms | 74.5 ms | 0.2% | EXAMPLE DATA — NOT VERIFIED |
| BUH-1 | AMS-1 | 34.2 ms | 38.8 ms | 0% | EXAMPLE DATA — NOT VERIFIED |
| BUH-1 | ZRH-1 | 27.5 ms | 31.7 ms | 0.1% | EXAMPLE DATA — NOT VERIFIED |
| RKV-1 | AMS-1 | 34.9 ms | 40.2 ms | 0% | EXAMPLE DATA — NOT VERIFIED |
| RKV-1 | ZRH-1 | 45.6 ms | 51.9 ms | 0.1% | EXAMPLE DATA — NOT VERIFIED |
| AMS-1 | ZRH-1 | 11.7 ms | 14.3 ms | 0% | EXAMPLE DATA — NOT VERIFIED |
Network disclosures
A city label is not proof. Publish the facility, originating ASN, announced prefixes, upstream networks, and a routable probe for each live region.
- Facility
- Example — replace
- Origin ASN
AS64512- Published prefixes
192.0.2.0/242001:db8:10::/48- Upstreams
- Example — replace
- Facility
- Example — replace
- Origin ASN
AS64513- Published prefixes
192.0.2.0/242001:db8:20::/48- Upstreams
- Example — replace
- Facility
- Example — replace
- Origin ASN
AS64514- Published prefixes
198.51.100.0/242001:db8:30::/48- Upstreams
- Example — replace
- Facility
- Example — replace
- Origin ASN
AS64515- Published prefixes
198.51.100.0/242001:db8:40::/48- Upstreams
- Example — replace
- Facility
- Example — replace
- Origin ASN
AS64516- Published prefixes
203.0.113.0/242001:db8:50::/48- Upstreams
- Example — replace
Public component status
Availability percentages are examples until backed by external monitoring and a documented calculation window.
| Component | State | 30-day availability | |
|---|---|---|---|
| Public website | Example — replace | 99.98% | EXAMPLE DATA — NOT VERIFIED |
| Control panel | Example — replace | 99.94% | EXAMPLE DATA — NOT VERIFIED |
| API | Example — replace | 99.91% | EXAMPLE DATA — NOT VERIFIED |
| Regional network | Example — replace | 99.97% | EXAMPLE DATA — NOT VERIFIED |
| Payment gateway | Example — replace | 99.88% | EXAMPLE DATA — NOT VERIFIED |
Incident history
The entries below demonstrate the expected chronology and disclosure depth; neither incident occurred.
DEMO-INC-2026-002EXAMPLE DATA — NOT VERIFIEDDEMO — Elevated packet loss on the AMS edge
Impact: Example impact: intermittent latency for a subset of routes
Example only: traffic was shifted to a secondary path while a simulated upstream issue was investigated.
- Started
- Resolved
DEMO-INC-2026-001EXAMPLE DATA — NOT VERIFIEDDEMO — Delayed payment webhook processing
Impact: Example impact: provisioning queue delayed after payment confirmation
Example only: queued callbacks were replayed after the simulated worker recovered.
- Started
- Resolved
Deployment changelog
Use this chronology for real, dated production changes. Never backdate releases or imply history that did not happen.
| Version | Date | Change | |
|---|---|---|---|
0.3.0-demo | DEMO — Added the operational evidence layout and editable JSON data model. | EXAMPLE DATA — NOT VERIFIED | |
0.2.0-demo | DEMO — Added example latency and benchmark methodology cards. | EXAMPLE DATA — NOT VERIFIED | |
0.1.0-demo | DEMO — Created the first transparency-center prototype. | EXAMPLE DATA — NOT VERIFIED |
Why the demonstration cannot be mistaken for proof
Invented numbers can explain a layout, but they must never be presented as uptime, latency, capacity, incident, facility, or network evidence. This build therefore uses reserved IP ranges, private-use ASNs, replacement markers, a prominent warning, and a dedicated verification flag. The transparency route remains noindex and absent from the sitemap while any demonstration marker remains.
The verified state is a release decision, not a cosmetic switch. A competent reviewer must check the source measurements, time window, commands, monitoring coverage, infrastructure ownership, and wording before the data file can be marked verified. If a fact cannot be substantiated, remove the field rather than estimate it.
- Do not replace the warning with a weaker disclaimer.
- Do not use private or documentation addresses as customer endpoints.
- Keep the raw measurement files and the exact commands used.
A useful looking glass exposes bounded tests
A production looking glass should let a prospective customer test reachability without exposing a management interface. Publish stable IPv4 and IPv6 probe addresses, DNS, ping and traceroute options, a small download object where appropriate, the originating ASN, and an abuse-resistant rate limit. State which region each probe represents.
The example endpoint uses the reserved .invalid domain and IANA documentation prefixes, so it cannot be confused with a working service. When real endpoints are connected, test them from several independent networks and keep the page useful without requiring an account.
- Separate public diagnostic endpoints from customer and management networks.
- Log minimally, rate-limit predictably, and disclose retention.
- Retest every address after routing or datacenter changes.
Benchmarks need a method, not a headline number
A reproducible result identifies the VPS shape, operating-system image, kernel, benchmark version, command, duration, concurrency, sample count, aggregation rule, date, and region. Median results from several runs are more informative than a single best run. Raw output should remain downloadable so readers can verify the summary.
CPU, storage, and network tests answer different questions and can affect neighboring workloads. Use bounded tests, follow provider limits, and explain that shared-host performance can vary. The example table is deliberately plausible enough to demonstrate the interface but has no evidential value.
- Publish both the command and the relevant environment details.
- Use the same test shape and duration across regions.
- Keep failed or slow runs in the raw record instead of cherry-picking.
Latency and network identity must be measurable
Latency depends on both endpoints, routing, congestion, time, and protocol. A serious matrix names the source and target, sampling period, probe count, median, p95, and packet loss. Measurements from the provider network alone should not be generalized to every customer access network.
Network disclosure should distinguish the contracting provider, facility operator, IP holder, origin ASN, transit carriers, and announced prefixes. These roles may differ. Publish current facts for each active region and change them when routing or suppliers change.
- Measure from networks that resemble the intended audience.
- Show a percentile and loss, not only an average.
- Link facility and ASN claims to records that can be independently checked.
Status history should explain impact and recovery
A public status page is credible when component states come from monitoring, the calculation window is defined, maintenance is distinguished from incidents, and degraded service is not hidden by an overall green badge. Each incident should record detection, customer impact, updates, mitigation, resolution, and a follow-up when appropriate.
The two incidents in this demonstration are fictional and carry DEMO identifiers. Replace them with real events only; an empty incident history is more honest than a fabricated track record. Availability percentages must be calculated from the underlying event history rather than typed into a marketing page.
- Use external probes as well as internal health checks.
- Publish timestamps in a clear timezone.
- Correct incident entries openly when later evidence changes the diagnosis.
A changelog is a factual deployment record
Record customer-visible product, network, policy, security, and reliability changes with the date they actually reached production. A changelog should help customers assess change and compatibility, not create the appearance of an older business. Group related changes and link to deeper migration or incident notes where useful.
The demonstration versions end in -demo and are not product history. Delete them when the first real deployment record is available. Do not backfill invented releases, rename prototypes as production milestones, or publish a date that cannot be supported by deployment records.
- Use the real production deployment date.
- Separate planned work from shipped work.
- Preserve corrections and security-sensitive disclosure boundaries.
Frequently asked questions
Are the current benchmark and latency values real?
No. Every current value is fictional demonstration data. Reserved addresses, private-use ASNs, visible labels, noindex, and sitemap exclusion prevent it from being represented as live evidence.
What must happen before this page can be indexed?
Replace every example with measured and independently checked data, remove every demonstration marker, validate the JSON, set its state to verified, obtain human approval, and only then enable the production verification flag.
Should an operator publish an empty incident history?
Yes, if no qualifying incident has occurred during the stated period. Publish the beginning of the measurement period and the incident definition; never invent events or uptime history to make the service appear established.