In brief
What a cloud portal's 99.9% uptime covers and what it leaves out. Which indicators show continuity on an on-site box. An honest comparison of both.
What does 99.9% promise?
Most cloud-based guest Wi-Fi services quote an uptime figure; 99.9% is a common one. The arithmetic is simple: one thousandth of 8,760 hours a year allows roughly 8.8 hours of downtime. That is not a bad number.
The question is what it covers. Usually the provider's own servers. Your internet line, modem, access points and SMS provider are not inside that figure. What matters to the guest is the end-to-end experience: does the portal open, does the code arrive, do they get online. And as the owner you care about one more thing: what happened to the Law 5651 records during the outage?
This article compares the two architectures honestly. Both have weak points.
The chain in a cloud portal
In a cloud architecture the guest's path is: phone → AP → modem → internet → cloud portal → verification → internet. The portal page and the verification run on a remote server.
When your internet line drops, the guest cannot get online; that is the same in every architecture. The difference is on the records side: if verification and logging live in the cloud, no new session and no record is produced while the line is down. When it returns, things resume. Details vary by design, so ask your provider "what happens while the line is down".
The chain on a box
On a box the path is shorter: phone → AP → box (portal, verification, records) → modem → internet. The portal page, session control and internal IP allocation records are produced on your premises, on the box.
When the internet drops:
- The guest still cannot get online. We do not hide that.
- A new guest cannot receive an SMS code, because the box sends SMS to the provider over the internet.
- The box keeps collecting internal IP allocation records for devices on the network.
- The daily digest cannot be timestamped; those days wait in a pending queue. When the connection returns they are stamped. The panel shows the number of pending days.
So an outage affects the guest but does not break the record chain.
What fails where
| Failure | Cloud portal | Box | Indicator on the box |
|---|---|---|---|
| Internet line | Portal does not open, logging stops | Portal opens, no internet, logging continues | Offline alarm |
| SMS provider | Codes do not go out | Codes do not go out; the backup provider chain takes over | Credit and delivery warning |
| Timestamp service | Depends on the provider | That day waits in the queue, stamped later | Pending-day count |
| Hardware (box / AP) | AP failure is the same for both | Box failure stops guest Wi-Fi | Offline alarm |
| Power | Everything stops | Everything stops | Offline alarm |
| Disk full | Not your problem | Your problem | Disk usage alarm |
The table shows two things. First, in the box architecture the failure points are under your control; that is both an advantage and a responsibility. Second, the box produces an indicator for every failure; there is no invisible fault.
How continuity is measured on a box
Instead of the cloud's single number, you watch a handful of indicators on the box. All appear in the panel and arrive as alarms by e-mail, Telegram or webhook:
- Offline status. If the box loses contact with the platform, an alarm fires. Whether the line or the power went, you will know.
- Pending-day count. The target is zero. Above zero means a timestamp service or line problem; no records are lost, only the stamp is delayed.
- Last successful timestamp. Shows the most recent day the chain was sealed.
- NTP drift. The box's clock is monitored continuously; if drift grows you get a warning. A wrong clock means wrong record times, which is why it is a separate indicator.
- Disk usage. Two years of records take space. An alarm fires when the threshold is crossed.
- SMS credit. Alarm below 100. If credit runs out, guests cannot sign in; that is an "outage" too.
There is also verification: one click in the panel checks the archive's SHA-256 chain and its timestamps. That closes the gap between "the system is up" and "the records are intact".
The second copy: if the box dies
A box is a single device, and every device can fail. Two measures shrink that risk:
- A second archive copy over SFTP/FTPS. The signed daily archive is copied off the box to your own server or NAS. If the box is lost entirely, the two-year archive survives in the copy and can be verified independently with
openssl ts -verify. - A spare box. Multi-site or outage-sensitive businesses keep a spare. A new box's chain starts on the day it is installed; the old archive is preserved in the copy. A new box does not sign retroactively, which is why the copy matters.
For power, a simple UPS keeps the modem and the box alive through short cuts. The box does not do this; you add it.
The honest trade-off
The cloud's advantage: Server maintenance, backups and hardware are the provider's job. You manage no device.
The cloud's cost: Records and verification sit outside your building. You have to ask the provider what happens while the line is down and how you reach the archive once the subscription ends.
The box's advantage: Records stay on your premises; they do not go to a cloud, abroad or to us. Logging continues through a line outage. Every failure maps to an indicator.
The box's cost: The hardware is your responsibility. Power, disk, the second copy and, if needed, a spare box belong in your plan.
No single uptime figure sums up either architecture. The right question is not "what percentage" but "what happens to the records and to the guest when something fails". The Box + Software page lists the indicators in full; contact us to talk through your own redundancy plan, or see the FAQ.