Analytics and operations

Analytics serves three different jobs: customer reporting, commercial reconciliation, and operational diagnosis. Pick the narrowest view that answers the question instead of exporting request-level data by default.

Proxy Metrics

Open Analytics → Proxy Metrics when the question is about current proxy behavior, infrastructure load, or upstream provider degradation. The summary cards show requests per second, active connections, throughput, and P95 request latency. The panels below add success rate and provider failures to the same time window.

Open full size

Use one scope across every operational signal before comparing gateways or upstream providers.

1. 1Live KPI cards summarize request rate, connections, throughput, and P95 latency.
2. 2Filter by cluster, region, server, protocol, provider, and an exact time window.
3. 3Request-rate series separate protocol behavior within the selected scope.

Open full size

Compare latency, completion rate, and upstream failure reasons over the same incident window before changing routing.

1. 1Success rate compares accepted requests completed by each provider.
2. 2Provider failures expose upstream error rates and failure reasons.

Use short windows for active incidents and expand the range only when you need a baseline; the maximum selectable window is 31 days. A warning means one or more panels are partial, while an unavailable state means the metrics datasource could not provide a usable dashboard. These states are evidence for an investigation, not automated remediation or an incident-history system.

Open full size

The overview keeps traffic trend on the left and popular domains on the right so volume and destination concentration can be read together.

1. 1Platform operating metrics summarize active users, capacity, providers, and invoices.
2. 2Scope by user, one or more packages, and an exact date-time window before comparing results.
3. 3Bytes, requests, package count, and average request size describe different operational signals.

Analytics surfaces

Surface	Best question	Important dimensions
Dashboard / overall	How much traffic and how many requests occurred over time?	Window, user, one or more packages, data/requests
Popular domains	Which destinations generated the most requests or bytes?	Hostname, package, customer, window
Request journal / feed	What happened in a user’s or order’s request stream?	Package, domain, protocol, method, route context, exact date-time window
Proxy logs	Why did a request fail?	Request ID, error code/message, status, user, destination, route and time
Connections	How many connections are active now?	User, package, server IP, connection count
Transactions	Who allocated, subtracted, or consumed data?	Sender, recipient, type, package, amount, timestamp
Resource charts	How is traffic distributed by provider, package, cluster, or server?	Resource identity, bytes/requests, date window, optional package scope

Use overall traffic for trends and closed-window totals; use popular domains for ranked concentration without downloading every request row. The protocol-and-method chart is platform-wide because those aggregate records do not contain a user identifier; it is intentionally not shown on a single-user edit page.

Date, time, and timezone

Use explicit start, end, and IANA timezone values when reproducing a report. Short windows can use hourly buckets; longer windows can use daily buckets. Store the requested window alongside any exported or reconciled result.

For request journals, defaulting to the previous 24 hours is a useful operational window. Allow both date and time input so support can isolate an incident without reading an entire day. Filters should permit all packages or one/multiple packages, protocol, and domain search where the view supports them.

Investigation workflow

1. Capture the customer-visible error, UTC/local timestamp, protocol, target domain, package, and request ID if available.
2. Confirm customer and order state, personal limit, active root ledger, source-IP policy, and connection limit.
3. Open the request journal for a narrow time range and filter by customer/order and package.
4. Match the domain, protocol, server, pool, geography, ASN, and session context.
5. If the request failed, inspect proxy logs for the same request ID or time/context and record the proxy error code and root message.
6. Compare provider, cluster, and server charts plus health and alert state for the same window.
7. Reproduce with synthetic credentials only when permitted, then document whether the cause is access, inventory, routing, upstream, gateway, or destination policy.

Structured application logs should include request ID, authenticated user ID, method, path, status/error code, exception type, root exception details, and a traceback for unexpected server errors. Keep secret fields out of that context.

Customer analytics contains sensitive data

Request rows can expose usernames, client/proxy IP addresses, destinations, location choices, and session context. Apply role-based access, retention, redaction, and export controls.

Reconciliation workflow

Webhooks can be delayed, retried, batched, or coalesced. Reconcile a completed period independently:

1. close the reporting window and save its scope and timezone;
2. read overall bytes and request totals;
3. compare with local customer, invoice, allocation, and webhook projections;
4. drill into transactions, request feed, domains, and logs only where totals differ;
5. repair the local projection with an append-only correction reason;
6. retain the source window and mappings used for the decision.

Do not calculate invoices from the number of webhook deliveries or request rows. Use defined commercial byte totals and durable entitlement state.

Alerts, incidents, and audit

Health and alerts

Detect provider or gateway degradation early and remove unhealthy targets from future route selection.

Incident history

Record impact window, affected packages/locations, mitigation, supplier reference, and resolution.

Audit log

Explain administrative configuration and balance changes separately from customer traffic.

Customer status

Publish only verified scope and avoid promising transparent replay or a new exit IP on every retry.

Distributed tracing is not a provided customer surface. Use request IDs, timestamps, user/order/package mappings, gateway context, feed rows, logs, health, and audit records to build the incident chain.

Continue with infrastructure and launch for capacity controls and production-readiness checks.