Peakhour.IO - Incident Response

What a Residential Proxy Decision Log Should Contain

2026-08-01T11:50:00+10:00

A log line that says proxy=true is intelligence. It is not a decision record.

When a customer asks why a login was challenged, a fraud analyst reviews an account event, or an engineer tunes a rate limit, the team needs to reconstruct what the control knew and what it did. A timestamp, IP address, and final risk score cannot answer that on their own.

Peakhour Residential Proxy Detection keeps the proxy result inside the request decision with IP, credential, device, behaviour, and route context. The record should preserve that connection without becoming an indiscriminate collection of personal data.

Record the Request Being Judged

The event comes first. The detector explains one part of it.

Useful request fields include:

observed_at
request_id and trace_id
service, host and route class
HTTP method
response status
account, tenant, session or API-key reference where permitted
edge location and origin target
cache outcome and whether origin was reached

Avoid logging secrets, complete session tokens, passwords, payment data, or unrestricted request bodies. The OWASP Logging Cheat Sheet recommends excluding or masking access tokens, authentication passwords, sensitive personal data, and other values whose collection creates more risk than operational value.

Use stable references where the investigation needs continuity, and keep their purpose and retention bounded.

Keep Signal Provenance

The value of a signal depends on how it was produced.

For proxy and network evidence, retain:

proxy_result and category
detector or feed name
detector version or dataset time
network type, ASN and country
client IP source and trusted forwarding hop
fingerprint method, version and capture point
browser or device evidence source

A fingerprint without a method and capture point cannot be compared safely. A country value without a source and observation time is difficult to audit after data changes. A forwarded IP taken from an untrusted header should never have reached policy in the first place.

Flattening every input into one number leaves the analyst with a threshold and no explanation. Retain the factors that moved the score.

Record the Policy and the Action

The event should identify the control that made the decision:

policy_id and revision
policy owner
mode: monitor or enforce
matched conditions
threshold and current counter state
selected action
action reason code
expiry or review date

Reason codes should be stable enough to aggregate. Free-text analyst notes can add context, but they should not be the only explanation.

The action field needs more detail than blocked=true. Distinguish allow, log, challenge, rate limit, deny, route, and step-up outcomes. For a limit, keep the key class and interval without exposing sensitive raw values. For a challenge, record whether it was presented, completed, failed, expired, or abandoned.

Connect the Decision to Its Outcome

Security controls are judged by what happened next.

Join the decision to:

successful login, signup, reset, checkout, or API completion;
authentication failure and account lockout;
challenge completion and abandonment;
429, deny, or step-up response;
origin request avoided or origin work created;
support case, analyst disposition, or confirmed incident where available;
policy rollback or exception.

This is how a team distinguishes attack reduction from customer suppression. If challenges rise and successful account recovery falls, the proxy policy may be adding friction in the wrong place.

NIST SP 800-92, the Guide to Computer Security Log Management, treats log management as a lifecycle of generating, transmitting, storing, analysing, and disposing of data. That lifecycle matters here. A detailed event that nobody can query, retain safely, or delete on schedule is not operational evidence.

Metrics Should Lead to a Decision

For an enforcement platform, useful measures should connect signals to route outcomes:

proxy prevalence by route and action;
percentage of proxy-labelled traffic allowed, challenged, limited, and blocked;
challenge completion for proxy and non-proxy cohorts;
legitimate transaction completion after action;
confirmed abuse caught with and without a proxy signal;
false-positive and analyst-overturn rates;
origin requests and application cost avoided;
time from observation to policy change;
rules past their review date.

A count of “risky sessions detected” is hard to act on. A rise in residential-proxy password-reset attempts with low challenge completion and repeated account failures can justify a route-specific change.

A Minimal Event

A compact decision record might resemble:

{
  "request_id": "req_...",
  "route_class": "account_recovery",
  "proxy": {"result": true, "category": "residential", "source": "resip"},
  "fingerprint": {"method": "ja4", "version": "pinned", "capture": "client_edge"},
  "credential_state": "exposed_match",
  "recent_outcome": "repeated_failure",
  "policy": {"id": "recovery-risk", "revision": 7, "mode": "enforce"},
  "action": "step_up",
  "reason_codes": ["residential_proxy", "exposed_credential", "failure_velocity"],
  "outcome": "pending"
}

The exact schema will differ by application. The contract should not: current request, signal provenance, policy revision, selected action, and measurable outcome.

The schema is ready when a support engineer can explain a challenge, an analyst can reconstruct an account event, and the policy owner can measure the result without opening a second system. Anything collected beyond that needs a stated security purpose and retention period.

Cloudflare outage proves Plan B depends on controlling DNS

2025-11-18T21:00:00+11:00

On Tuesday, 18 November 2025, Cloudflare’s own status page marked every major service—CDN, Firewall, WARP, Workers, and the dashboard—as degraded for most of the day while engineers worked through an internal control-plane failure. The timeline moved from “Investigating” at 11:48 UTC to “Monitoring” after 14:42 UTC, and the incident wasn’t officially resolved until 19:28 UTC. During the worst of it, Cloudflare disabled WARP in London, bot scores seesawed, and customers were told to wait while remediation continued.

Waiting was the only option for many teams because their Plan B lived behind the same dashboard that was timing out. The top comment on the Hacker News thread was a set of curl commands for moving domains off Cloudflare’s proxy edge. Admins were stuck in 2FA flows trying to fetch an API token, or searching for Terraform credentials so they could toggle a proxied flag. That is not a resilience strategy.

We learned this lesson the hard way—and wrote about it after the 2021 Fastly outage in How to have a Plan B. The rule still stands: the platform you are trying to leave cannot be the only place that can change where your DNS points.

Detect: understand what’s actually broken

Incidents like Tuesday’s change shape quickly. Cloudflare’s own feed showed different failure domains every 30 minutes: bot management, dashboard auth, Access, WARP. The first mile is impartial telemetry that tells you what your users feel, not what the provider thinks. At Peakhour we stream real user monitoring, synthetic checks, and control-plane health from multiple CDNs and DNS partners. That lets us distinguish “cache errors in Hong Kong” from “global auth outage” and choose the right lever.

Decide: keep DNS authority in neutral territory

When your domain delegation lives with agnostic providers—Route 53, NS1, Azure DNS, or the enterprise registrar your legal team already approved—you can make failover decisions without pleading with a failing control plane. Peakhour doesn’t replace those vendors; we orchestrate them. We set short-but-safe TTLs, keep secondary answers staged, and continuously audit API access so we can flip traffic with one signed request. The minute you outsource DNS authority to a proxy CDN, you have given up the control that makes Plan B possible.

Divert: run the playbook in minutes, not hours

A workable Plan B has three moves:

Pre-stage alternate edges. Your secondary CDN, origin, or transit provider must be in sync with the active one—certificates, cache rules, WAF policies, everything. We keep them hot by replaying production configs across vendors.
Wire DNS automation. We integrate with multiple third-party DNS APIs at once so we can update apex A/AAAA, flattened CNAMEs, and geo/latency rules in a single workflow. Because the automation lives off the impacted platform, we can execute even while Cloudflare’s dashboard is returning 500s.
Drill humans on the handoff. Our SOC sits in Sydney and Melbourne, but we cover global hours. During an incident we line up Slack/Teams bridges with your SREs, confirm business impact, and keep execs in the loop while traffic drains to the healthy provider.

With that in place we routinely hit sub-five-minute diversion times, including DNS propagation, because the decision, the tooling, and the people are ready before the outage hits.

What Peakhour brings to your Plan B

Independent authority, familiar vendors. We leverage multiple established DNS providers instead of locking you into ours. You keep your contracts; we bring the automation and guardrails.
Unified multi-CDN config. Cache rules, image optimisation, WAF, and routing policies stay aligned across providers so you don’t lose capabilities when you switch.
Real drills, not just runbooks. Quarterly failover exercises prove that certificates, APIs, and humans are ready. We share the post-mortems so your execs see clear RTO/RPO numbers.
People you can phone. 24×7 Australian-based engineers who know your stack and can execute the play while your own team communicates with customers.

Book a resilience review

If Tuesday exposed that your failover path still depends on your primary provider’s dashboard, book a 30-minute Resilience Review with Peakhour and we’ll:

Map who really controls your DNS today.
Identify the gaps between your primary and standby CDNs.
Outline the automations we can layer on top of your existing DNS and hosting vendors.

The output is a concrete Plan B, a drill schedule, and a team that can execute it the next time a global provider blinks.