Should I delete a burned Multilogin profile?

No — move to burn tier in CMDB and profile pool. Clone for forensics; keep original for appeal evidence and fingerprint diff audit.

Ban on web layer only — is cloud phone safe?

Not automatically. Audit CMDB for shared IP, cookie export, or staff VPN. Mobile layer may be linked if identity signals crossed.

Multilogin Ban Recovery Runbook

When a seller account, ad account, or social profile gets restricted, teams panic and make it worse — re-login loops, shared IP reuse, automated appeals. This runbook is the **first 60 minutes** after a ban signal on any platform using Multilogin (web) and cloud phone (mobile).

Phase 0 — Stop the bleed (0–5 min)

Pause automation — drain mlx:jobs queue for affected client_id
Release leases — no new CDP attach on burned profiles
Tag CMDB — ban_status=suspect → confirm → burned
Move profile pool — sync to burn tier
Alert ops — Slack with job_id, platform, profile_id, device_id

Phase 1 — Triage: web vs mobile vs both

Signal	Likely layer	First check
Seller Central 403 / verification loop	Web (Multilogin)	Proxy ASN change, fingerprint drift
TikTok app shadowban / device trust	Mobile (cloud phone)	Emulator flag, IP geo mismatch
Both restricted same day	Linkage	Shared IP, cookie export, same staff VPN
Multiple accounts same client	Agency contamination	Proxy pool reuse, workspace bleed

Phase 2 — CMDB audit checklist

account_id: ...
mlx_profile_id: uuid-...     # web layer
cloud_device_id: ...         # mobile layer
web_proxy: us-isp-sticky-44  # last 7 days stable?
mobile_proxy: us-mobile-07  # same country, different endpoint?
geo: US
last_cookie_export: never    # red flag if yes
staff_vpn_used: false
linked_accounts: [shop_b, shop_c]  # any also suspect?

Hybrid architecture reference: hybrid CMDB · VI: bản tiếng Việt.

Phase 3 — Platform-specific notes

Platform	Common cause	Recovery path
Amazon	IP reputation, linked entities	Human appeal only; new sticky ISP; never auto-submit
eBay	Managed payments geo jump	Stop automation; manual case via Seller Hub
Etsy	Star Seller SLA + IP share	Audit cross-listing CMDB proxy assignments
TikTok Shop	App/web layer mix	Separate re-warm; see TikTok ban checklist in guide
Shopee/Lazada	Staff VPN vs shop geo	Replace VN/SEA sticky proxy; human KYC
Mercado Libre	LATAM geo mismatch	Country-matched proxy; Mercado Pago manual only
Allegro	PL/EU geo jump	PL sticky proxy; human appeal only
Meta ads	BM linkage, fingerprint	Run fingerprint audit; do not create new BM on same IP

Phase 4 — Technical forensics

Fingerprint audit — diff manifest vs last known good
Profile debug — zombie Mimic, orphan CDP
Proxy history — did sticky session ID rotate mid-week?
DLQ review — ban-class jobs in last 48h
Metrics — ban_rate spike before incident

Phase 5 — Recovery decision tree

Suspect (not confirmed ban)
  → keep in warm tier, human login test, no automation 7 days

Confirmed restriction, single account
  → burn profile + device in pool
  → new proxy session ID (never reuse burned IP)
  → new profile OR clone with new proxy (human warm 14 days)
  → human appeal if platform allows

Cluster ban (3+ accounts same client_id)
  → STOP all accounts under client
  → audit agency workspace separation
  → review shared proxy provider / staff access
  → executive review before any re-launch

What never to automate

Platform appeal forms, identity re-verification uploads
Bank / tax / KYC document submission
Mass re-login across burned profiles to "test" status
Cookie import from burned profile into new profile

Automation hooks (post-incident)

# DLQ ban class → auto burn (from dlq-handler recipe)
if error_class == "ban":
    sync_pool(profile_id, tier, "burned")
    notify_slack(...)
    # NO auto-replay

Profile pool manager Clone & forensics Grafana dashboard DLQ handler Observability Hybrid architecture Pre-launch checklist Code hub

Disclosure: MLX-MMO affiliated with Multilogin. Platform policies vary — this runbook is technical ops guidance, not legal advice.