System status.

Each row is a status we assign, not a light wired to a single metric. A component only shows Operational when our own checks and the absence of member reports both agree that it is behaving. When they disagree, we investigate first and update this page the moment we confirm a real problem.

What the four states mean

Operational means the component is doing what it was designed to do, at the speed it was designed to do it. Error rates and latency are inside their normal bands.

Degraded means the component works, but not to our standard. Messages still arrive but slower than they should, or a fraction of requests need a retry. Most members may not notice a degraded component at all; we flag it anyway, because you deserve to know when we are not at full strength.

Outage means the component is down or failing for a meaningful share of members. An outage on any row puts everything else we are doing on hold until it is resolved.

Maintenance means we took something offline on purpose. We design maintenance to be invisible, and when it cannot be, we say so here before it starts, not after you notice.

The hands that wrote it are the hands that watch it

Vronify.chat was hand-written from zero to over 125.000 lines of code, with no template or white-label product underneath, and it runs on hardware we own and tune ourselves. That changes what monitoring means. When a graph twitches, there is no vendor to file a ticket with and no black box to guess about: we know which line of code owns that graph, because we wrote it. The small team in the Netherlands that built the platform is the same team that watches it.

Checked from the outside, not just the inside

Internal metrics lie by omission. A server can report itself perfectly healthy while nobody outside can reach it. So on top of internal health checks, we continuously test the platform the way a member experiences it: does the app load, does a sign-in complete, does a message make it from one account to another, end to end. A component on this page turns green only when the outside view agrees with the inside view.

What good looks like

We do not monitor against vague thresholds. The targets are public and specific: message delivery under 40 milliseconds at the median in Europe, and 99.9 percent uptime, which is where we have held across the last 12 months. When a number drifts away from its target, we investigate before it becomes something you would notice, and long before it becomes an incident. The reasoning behind those numbers, and how we hit them, is on the performance page.

Members beat monitors

If you are seeing a problem this page does not show, tell us through support. Real reports from real members beat any monitor we could write. Our checks run from a handful of vantage points; you run from thousands. Some of the most useful signals we get are three members in the same hour saying the same thing our dashboards have not caught yet.

The honest limits

Two things this page cannot do, said plainly. First, it is served from vronify.chat itself, on our own hardware, because we will not route your visits through a third-party status vendor: we run zero trackers, ads, or data brokers, and that applies here too. The trade-off is that in the worst possible failure, the one that takes the whole domain down, this page goes with it. Second, our monitoring ends at our edge. It cannot see your device, your browser extensions, or your ISP, which is why a green page and a broken session can occasionally both be true. The FAQ below covers what to check when that happens.

The line matters in both directions. Calling everything an incident trains you to ignore this page; calling nothing an incident makes it decoration. One category always escalates regardless of size: anything touching security. A cosmetic bug can wait for the next release. A security question cannot, and if you have found one, the vulnerability disclosure page tells you exactly how to reach us.

No incidents in the last 90 days. Uptime over the last 12 months sits at 99.9 percent, and the thinking behind that number is on the performance page.

When an incident does happen, its entry stays on this page permanently. Each one records when it was first detected, when it was mitigated, when it was fully resolved, which components were affected, what caused it in plain language, and what changed afterward. We write these for members, not for lawyers: if the cause was our mistake, the entry says so.

We also do not edit history to look better. Entries are corrected if we learn something new, and corrections are marked as corrections. A status page you cannot trust in hindsight cannot be trusted in the moment either.

Why the history is short

A quiet history is not luck, and we would rather show you the reasons than ask you to take it on faith. The platform runs on hardware we own and tune ourselves, so there is no noisy neighbor and no surprise migration. The codebase is a single hand-written stack rather than a pile of glued-together services, so there are simply fewer seams to split. And changes ship deliberately: you can watch the pace yourself in the changelog. None of that makes incidents impossible. It makes them rare, and it makes the ones that happen easier to understand and faster to fix.

If you are seeing a problem this page does not show, tell us through support. Real reports from real members beat any monitor we could write.