An IP address is not a subscriber: reading client identity in Hostwatch
One customer can open thousands of connections. One public IP can carry several customers. Hostwatch needs to show both facts without treating every limit as an attack or every paired device as a subscriber.
Published 23 October 2026. Hostwatch engineering review; implementation limits are stated below.
The same traffic can answer four different questions
Start with a connection to an application relay. Its source has an IP address. The connection may prove possession of a pairing key. The application may independently prove a signed-in account and an active subscription. The request then receives an admission decision under a particular policy. These observations are related, but none should overwrite the others. A paired device can arrive from an external network. A verified subscriber can reach a device concurrency limit. A familiar IP can also send a request with no valid account proof. The dashboard should make those combinations understandable rather than force each client into one universal “ours” or “external” bucket.
In Hostwatch, the useful dimensions are application identity, device or service evidence, network origin and request outcome. The first two describe what was proved. Network origin describes where the request arrived from under the configured evidence. Outcome describes what the relevant policy or protection layer did. Keep the selected server, application and time window visible as well. A summary for all configured applications cannot be compared directly with a single relay’s open connections. If the operator has to guess which denominator a card uses, even accurate backend counters will produce a misleading investigation.
Let the application prove the account and subscription
The application is the authority for its accounts and subscription state. Hostwatch’s admission integration consumes fresh, verified account/device proof rather than accepting an account ID or paid label sent by an arbitrary public caller. A configured adapter needs to preserve the relevant application scope and proof lifetime. When that proof expires, the system must not keep presenting an old entitlement as current. Equally, a missing integration should remain missing coverage. The presence of a connection, an address in a known country or a recognizable User-Agent cannot fill the gap.
A pairing credential proves a narrower fact: the caller possesses the permission used to pair an application device or session. That can be legitimate and useful without identifying a billing account. Treating all paired traffic as public anonymity hides useful evidence; treating it all as a paid subscription invents stronger evidence. Hostwatch’s categories therefore keep paired-device attempts separate from subscriber, test-access, signed-in and public checks. For an operator integrating another application, the first task is deciding which authority can establish each category and testing the adapter’s failure path. A dashboard setting cannot manufacture account verification that the application never supplied.
Count checks, connections, IPs and people separately
An admission check is an event, not a person. A connection attempt is not the same as an open connection, and neither is a unique account. Reconnect loops, multiple devices and short-lived sessions can produce many events for one legitimate user. Presenting the event count as a customer count makes a small system look unexpectedly crowded and makes policy limits difficult to interpret. Hostwatch labels checks and connection attempts explicitly, while private application-capacity collectors report account and device populations separately when an authenticated source can provide them. Unknown collector values remain unknown.
Distinct IPs add another useful measure, but they answer a network question. Many people may share an address; one person may change networks. Show the number of recorded addresses next to the count of events with address evidence, then let the operator open the top IPs and inspect their categories and reasons. If earlier admission events were stored without an address, their original event totals remain valid while their historical distinct-IP count is unavailable. Do not infer those old addresses from today’s sockets. Collection start time and coverage explain the discrepancy more honestly than a zero that appears to describe the entire selected window.
A customer allowance is different from attack mitigation
An active subscriber should receive the allowance for that account and device, rather than inherit a blanket penalty because another user shares the same network. That does not make subscription proof an unlimited bypass. A compromised or malfunctioning paid client can still consume excessive capacity. The admission manager has separate account, device and connection controls, with explicit decision reasons such as account-rate or account-connections. The operator needs to see which allowance was reached and which identity it applied to. Changing the network limit will not repair an account limit that was set incorrectly.
Keep those decisions apart from attack enforcement. A recorded application or proxy rate limit describes a policy outcome; a verified Hostwatch mitigation requires its own rule evidence. A 429 or a closed connection alone is not enough to classify an attack. In the dashboard, admission limits belong beside admitted checks with their reasons. Verified mitigation belongs in the protection outcome. Ordinary application failures retain their own count after attributed protection is excluded. These distinctions allow an operator to investigate a noisy legitimate client without celebrating its failed requests as successful defense or mixing intentional limits into the application’s crash rate.
Known infrastructure can still arrive from a public network
A request from an owned service may cross a public interface. A customer may connect through the same provider or geographic region as that service. Neither the country nor the provider proves ownership. Hostwatch’s network-origin groups distinguish configured known networks, external networks, private networks and unknown origin. A known-network classification should come from reviewed configuration or authoritative evidence for that scope. Avoid labelling a whole hosting provider as “our services” merely because one of your workers runs there. That shortcut can turn unrelated traffic into trusted internal activity.
For inspection, combine the network grouping with identity evidence rather than replace one with the other. An IP detail should help answer which application it reached, which accounts or paired devices were proved, how many checks were admitted or limited and what reasons were recorded. The account association applies to the recorded authenticated activity, not every packet from the address. Redact session material and sensitive query values in examples. The goal is operational context for a bounded investigation, not a new directory of customer identity inferred from network traces.
Investigate a large number before changing its policy
When a card looks implausibly large, first confirm its scope and unit. Is it one application or all sites? Does it count HTTP checks, WebSocket attempts or sockets open now? Does the period match the graph above it? Next inspect the largest category, open its IP grouping and compare the frequent reasons. Look for repeated attempts from the same recorded source and a sudden change in the connection pattern. Then consult the application’s authenticated capacity collector, when configured, to compare actual accounts and devices. This sequence can reveal a reconnect storm without turning it into a fictitious customer surge.
Only then adjust a specific allowance or repair the client. A repeated reconnect may need backoff or a lifecycle fix; increasing every limit can amplify the original problem. A genuinely restrictive account policy may need a tier-specific change. An unexplained external burst may need a separate behavior investigation. Record the change and compare accepted activity, limited activity and application health afterward. The right result is a usable service with a defensible explanation for the remaining limits. A lower count of purple bars is not enough if the client simply stopped reaching the application.
Prove the integration one application at a time
For a new Hostwatch application adapter, use controlled test identities to verify public access, pairing, signed-in access, active entitlement, expiry and revocation. Check the transition between categories, not just their initial labels. Open more than one device and more than one account from the same network to confirm that the intended policy separates them. Exercise a stale proof and an invalid proof. Check that renewal preserves legitimate connection evidence without upgrading an unverified client into a subscriber. Keep these tests separate from production totals and mark synthetic identities so they cannot inflate real customer metrics.
Finally, compare the web view, mobile view and underlying decision record for the same application and interval. They should agree on category, outcome and reason even when their layouts differ. A reader should be able to open a summary, inspect an address and reach the relevant retained evidence without losing the selected scope. Coverage limitations must survive that drilldown. This is the standard Hostwatch’s identity reporting is built toward: accurate proof boundaries, explicit limits and useful navigation. It does not promise that every historic event has an IP or that every connected device is linked to a subscription.
Read four facts separately: what identity the application proved, which device or service is involved, where the connection came from and why this particular request was allowed or limited.