Residential Proxy Project Offboarding: Reconcile Tasks, Access and Residual Usage

A residential proxy project is not closed merely because its main script has stopped. A scheduled runner can restart it, another worker can still hold a connection, and a shared account can hide the project's remaining traffic. Close the project against three records: its task inventory, its access inventory, and its usage evidence.

This guide applies to the planned end of an authorized website test, advertising verification, or market research project. It is an operating procedure to adapt and validate, not a claim that these actions have been performed on your account. Suspected credential exposure needs your incident process rather than a slow routine closure.

1. Set a closure boundary and name the owner

Record a project ID, owner, approved stop time with timezone, task names, workers, proxy resource references, authentication mode, and evidence retention date. Include periodic jobs, queue consumers, retry workers, CI schedules, browser profiles, local utilities, and external schedulers that you actually control. An empty workstation is not an inventory of the whole project.

Classify every dependency as project-exclusive, shared with a named continuing project, or unknown. Keep secrets out of the inventory: use vault references and masked identifiers. Unknown ownership blocks a destructive change to that dependency; assign an investigation owner instead of assuming it can be removed.

2. Distinguish access, allocation, and commercial obligations

Consult the 98IP dynamic residential IP page to identify whether your setup uses API extraction, username/password extraction, or an allowlist-based mode. Trace both the ability to obtain proxy endpoints and the ability to use already obtained endpoints. Removing a downloaded endpoint list is not evidence that its upstream access has been revoked.

If the project uses a resource described on the static residential IP page, record its actual allocation and expiry separately. Stopping traffic does not, by itself, establish that an allocation is released, an order is cancelled, renewal is disabled, or a refund is due. Verify the controls and terms available for your actual account; this guide does not assert an unverified one-click revoke or cancellation feature.

3. Stop new work before draining existing work

1. At the approved cutoff, disable the project's triggers and new queue intake in each scheduler that owns them. Record the scheduler's disabled state and the last scheduled execution.
2. List running jobs and decide, within the project authorization, which may finish and which must be cancelled. Use a bounded drain deadline; an indefinitely retrying task is not a completed closure.
3. Stop the affected workers and close their connection pools or browser contexts after the approved drain. Record queued, running, completed, and cancelled counts separately.
4. Keep a continuing project as a control where resources are shared. Confirm that its scheduler and a harmless authorized request still work after the project-specific changes.

A supervisor, deployment system, or CI schedule can recreate a stopped process. Check the controller as well as the process. Do not test closure by waiting for another production crawl to run; use a small owned test job or inspect the scheduler's next-run state.

4. Remove access at its real scope

For a project-exclusive authentication identity, use the supported account controls to revoke or replace the access that is no longer required. Check API extraction credentials, runtime proxy credentials, secret-store grants, and relevant allowlist entries independently. A single change may not cover every access path.

For shared credentials or a shared NAT allowlist address, first identify the continuing consumers. Establish their replacement access using supported controls and verify them before withdrawing the shared access under an approved change plan. If project-level isolation is unavailable, record that limitation and arrange the broader change with the responsible owner; do not report project-only revocation as complete.

Do not assume credential changes instantly terminate existing tunnels. Verify the provider's actual behavior and close the retired project's own clients. After validation, remove obsolete configuration and local secret copies under your retention rules. Keep the closure evidence free of secret values.

5. Use a paired access check, not an unexplained error

Where your authorization and provider controls permit it, use a fresh client to make one minimal request to an owned diagnostic endpoint with the retired access. Check the relevant extraction path separately if it existed. Record only whether access was accepted or rejected and the safe error category. Prevent fallback to direct access or another credential; otherwise a successful response may conceal the retired identity being refused.

At the same time, verify a continuing authorized control path. Old access rejected while the control succeeds supports the intended access boundary. Both failing could be a service or network outage. A transport timeout alone does not prove revocation. For allowlist access, test from the actual affected source environment rather than a laptop with a different public address.

6. Reconcile residual traffic with a timed observation window

The 98IP dynamic residential IP FAQ describes account usage statistics by hour, day, and month in the user console. Take a baseline at the cutoff and compare later observations on the same time basis. Account-wide figures are useful, but they cannot uniquely attribute traffic to one project when other projects share the account.

Set a documented observation window that covers the known scheduler and retry intervals plus the reporting delay you have actually established. If reporting delay is unknown, leave a follow-up open instead of declaring an instantaneous zero. Compare worker logs, remaining queues, and available usage records. Record timestamps and units; an hourly chart viewed in another timezone can mislead.

If usage rises, check continuing projects first, then forgotten retry consumers, resumed CI runners, and clients that retained old connections. Do not label the increase as abuse without evidence. If the provider does not expose project-level usage, state that attribution remains limited even after the local shutdown checks pass.

7. Finish with three independent closure decisions

• Work stopped: triggers are disabled, outstanding work is accounted for, and retired clients are closed.
• Access removed: supported controls and a valid paired check establish the intended boundary, or the remaining shared-access limitation has a named owner and an open action.
• Usage reconciled: the observation window is complete, residual activity is explained within the available attribution limits, and allocation or commercial follow-ups are separately recorded.

Do not mark the entire project closed if one decision remains unresolved. Preserve a small redacted evidence bundle, not exported cookies or complete proxy credential lists. Delete collected test data when its approved retention period ends, with any required holds handled by the responsible owner.

FAQ and a rehearsal checklist

Is stopping a script enough to stop charges? It only proves that process stopped. Usage, shared consumers, allocations, renewal settings, and contract terms require their own checks.

Should an old secret be restored if a continuing job breaks? Investigate the missed dependency and use approved current access. Reopening retired access without a scoped decision can undo the closure boundary.

Before a real closure, rehearse with two synthetic projects in an isolated environment: retire one while keeping the other healthy; leave one test scheduler enabled and confirm the inventory catches it; introduce a known delayed usage record and confirm the process leaves reconciliation pending. These are suggested exercises, not executed results or guaranteed provider behavior.

Perform all changes only within the account and resource owner's authorization. Do not disable shared customers' work, cancel commercial services, or delete evidence outside the agreed closure scope. A project owner's sign-off should identify what stopped, what remains shared, and who owns every open action.