How We Measure Uptime — and What It Covers
Uptime numbers only mean something when the method is clear. This page explains what Graviix counts as available, how the 99.9% service target applies, how incidents are communicated, and what happens when a request fails.
What counts as uptime
We measure availability at the routing layer: whether the proxy endpoint accepts authenticated connections and can establish an upstream connection to a target. A successful probe requires a completed TCP connection and an HTTP response from the endpoint. Target-site errors are recorded separately, because a 403 from a website does not mean the proxy network is down.
- Probes run from multiple regions at short intervals.
- Authentication failures caused by customer credentials are excluded from network availability.
- Target-site blocks, CAPTCHAs, and timeouts are tracked as request outcomes, not as platform downtime.
- Planned maintenance is announced in advance where practicable.
The 99.9% service target
The 99.9% figure used across our product pages is a monthly service target for the routing layer, not a guarantee that every individual request will succeed. A single IP can be rate-limited by a target at any time; that is normal for any proxy network. The target covers the availability of the service that accepts and routes your traffic.
| Scenario | Counts against service uptime? |
|---|---|
| Proxy endpoint unreachable for your account | Yes |
| Authentication service outage | Yes |
| Target website returns 403 or 429 | No |
| Your script uses an expired password | No |
| Scheduled maintenance inside the announced window | No |
How incidents are handled
Detection
Automated probes and error-rate alerts notify the on-call team when routing availability drops below the expected range.
Mitigation
Traffic is shifted away from affected capacity where possible. Failover is automatic for supported plans.
Communication
Affected customers are notified by email for incidents that materially affect service. Support can provide status updates on request.
Review
After a significant incident we review the cause and adjust monitoring or capacity to reduce repeat failures.
If a request fails
Start with the status code. A 407 points to credentials, a 429 points to target-side rate limiting, and a 502 or 504 points to an upstream connection problem. Retry transient failures with backoff, rotate the session, and lower concurrency before assuming the network is down. The documentation lists the codes and what to check for each.
When contacting support, include the timestamp in UTC, the proxy user, the target URL, the status code, and any request ID. That information shortens investigation time considerably.
Reliability questions
Do you publish a live status page?
Incident communication is currently handled by email and support. If you need a status feed for procurement or monitoring, contact us and we will share the current process for your account.
Is uptime the same for every proxy type?
No. Residential and mobile capacity is shared and can fluctuate with demand. Datacenter and static ISP endpoints are more predictable, which is why they are often used for latency-sensitive work.
What should I do during a suspected outage?
Retry a simple request to a neutral endpoint such as httpbin.org/ip, check your credentials, and contact support with the details listed above if the failure persists.
Do you offer service credits?
Credit terms depend on your plan and contract. Contact support with the incident details and account information so the team can review eligibility.