Uptime and availability tell different stories.

Define what “up” means.

In a proposed proxy monitoring setup, an uptime check might ask whether a gateway accepts a connection and completes a small probe. That tells you something about reachability. It does not establish that every exit address works, that every country can be selected, or that a destination accepts the resulting traffic.

Availability needs an equally explicit definition. On this preview, the label represents an illustrative valid-response ratio: attempts that produce the expected result divided by eligible attempts. These are definitions for our example interface, not universal definitions shared by all providers.

A response code is part of the answer.

A successful HTTP status can accompany content that is useless to your workflow. For example, an application could receive a generic page where it expected a particular record. Conversely, an error can originate from the destination or an intermediary rather than the proxy gateway. Google’s monitoring guidance distinguishes explicit failures from responses with incorrect content.

Keep the HTTP code, connection outcome, and content-validation result as separate fields. Cloudflare’s status-code documentation also distinguishes edge and origin responses. When a request passes through several systems, recording only one final code can erase useful context.

Write down the denominator.

Consider a fictional test with 1,000 scheduled attempts. Suppose ten never start because the test runner is offline, twenty cannot connect, and thirty return invalid content. You could calculate several different percentages from that record. None should be published without explaining which attempts are included.

Decide in advance how runner failures, user cancellations, retries, and maintenance periods are treated. Preserve the raw counts alongside the percentages. A smooth chart without a sample count makes it difficult to tell broad evidence from a handful of requests.

Look at interruption shape.

Two services can have the same aggregate success ratio and feel very different. Scattered isolated failures may be handled by a retry policy; a continuous interruption may halt a whole pipeline. Keep an event timeline and record consecutive failures so the duration and concentration of problems remain visible.

Compare regions separately before aggregating them. A global summary can be dominated by the busiest route and conceal an issue on a smaller route that matters to your team. An explicit traffic weighting is more informative than an unexplained global percentage.

What the preview can tell you.

ProxyAtlas currently demonstrates these views with simulated values. Its uptime bars do not report incidents, and its availability percentages are not provider ratings. The useful part of the preview is the structure: distinct signals, visible context, and a way to explore regional differences. Real collection and incident reporting are outside this release.