← back to blog

Audit your fleet: reading the login and device history every account already shows you

You kept your accounts apart the hard way: separate proxies, separate profiles, separate inboxes, a different fingerprint on every one. Then you closed the laptop and stopped looking. But the accounts never stopped writing things down. Each one keeps a quiet record of every place it was opened from, every device that touched it, every session still hanging open somewhere. The platform reads that record constantly. You almost never read it once. This is about auditing your own fleet the way a platform would, reading the login history and the device list an account already hands you, and catching the link you missed before it catches you.

Why I audit my own fleet

I run proxy and cloud phone farms and manage large fleets of separate identities, and the accounts I lose are almost never the ones I planned badly. They’re the ones I stopped checking. A setup isn’t something you build once and trust forever, because it drifts. A helper logs in the fast way, a phone you forgot is still holding a session, a proxy quietly goes bad and reroutes an account. I audit because the wall I built in January isn’t the wall standing in June, and the only way to know which one I have is to read what each account says about itself.

The account already shows you what the platform sees

Here’s the part people miss. You don’t need a special tool to see how an account looks from the outside, because most platforms hand you a version of it for free. Buried in the security settings of nearly every serious account is a page that lists recent logins, and a page that lists active devices and sessions. That’s the platform showing you some of the very signals it uses to decide whether the account is one calm person or one node in a farm. It’s a mirror almost nobody looks into.

Read the login history first

Start with the login history, the timeline of every recent sign in. Each line usually carries a time, a rough place, an IP, and a guess at the device. Read the whole thing as a story and ask it one question: does this look like one person living one life. A real user signs in from a handful of familiar places at ordinary hours. If a single account hops between cities, changes networks between sessions, or logs in at three in the morning local time every day, that’s the shape of something driven from a panel. Read the clock too, since the hours an account keeps are their own signal, and login times clustered on your real waking hours instead of its supposed local ones contradict the profile.

The device list is the body count

Then open the active device and session list, the roster of everything currently logged in. This is a body count, and it’s often the most honest page in the whole account. Every phone, every browser, every stale session you forgot to close is sitting right there with a name and a last seen time. If an identity you thought lived on one cloud phone is showing four devices, three of them are leaks you didn’t know were open. Count the bodies on every account and make that number match the story you meant to tell.

One account, one story

The standard you’re auditing against is simple. Each identity should show one consistent device and one consistent place over time, the same body living in the same neighborhood. That’s what an ordinary human account looks like from the inside, because that’s what an ordinary human is. You’re not hunting for anything clever here. You’re checking that every account you hold reads as boring, singular, and stable, and flagging the ones that read as busy, plural, and roaming instead.

The contradiction is the tell

What a platform actually hunts for is the contradiction, the internal disagreement an account makes with itself. An account that claims one country in its profile but keeps signing in from another. A session that appears in two distant places within the same hour, which no single body can do. A device that swears it’s one kind of phone while the browser underneath reports another. None of these needs a second account to prove anything. The account convicts itself, and your audit is you finding that contradiction before the platform runs the same read on it.

Now widen from one account to the whole fleet, because the loudest link only shows up when you line the records up side by side. Lay the device lists of ten identities next to each other and look for the same body appearing in more than one. The same browser fingerprint, the same phone name, the same machine touching accounts supposed to be strangers. That repeat is the single strongest thread a platform can pull, and you’ll never see it auditing one account at a time. The fleet view is where the shared device stops hiding.

The shared address across the list

Do the same pass for the address. Read the IP and the rough place on every account’s login history and watch for the one that shows up under identities that should have nothing in common. Maybe a proxy expired and three accounts silently fell back to your home line. Maybe a helper opened four of them from one office. The login history is where that quiet collapse becomes visible, one address stamped across a row of accounts that were each supposed to be their own. Find the shared line and you’ve found the afternoon your isolation broke.

The forgotten session is a live wire

Pay special attention to the old session nobody closed, because it’s a live wire. An account you moved onto a new phone months ago can still show the previous device logged in, still reporting in from wherever it sits. That stale session is a second body on an identity you thought was clean, quietly reporting a place you stopped using and a machine you meant to retire. Every forgotten session is a link waiting to be drawn, and the device list is the only place it will admit it’s still hanging there.

Recovery details are part of the audit

Don’t stop at logins and devices, because the recovery details are their own audit. Open each account and read the email and the phone number attached to it, the way back in that survives a lost password. This is where fleets link at a level nobody checks: one personal number sitting under a dozen identities as the shared recovery, one inbox that quietly reaches all of them. The login history can look spotless while the recovery field ties everything together underneath. Audit the recovery the same way you audit the logins, and make sure no two identities share a road back in.

The login method leaks too

One more field people skip: the method the account signs in with. An identity that logs in through the same Google or social account across your whole fleet is linked by that shared login no matter how separate the proxies and profiles are, because you’ve handed the platform one identity provider that sees every one of them. Read how each account authenticates, not only where it connects from. A shared sign in method is a link you built on purpose without realizing it was a link at all, and it hides in a field the plain login history doesn’t even show you.

Build a fleet audit sheet

None of this survives inside your head, so build a sheet. One row per identity, and columns for what it should show against what it actually showed the day you looked: the devices, the address, the timezone, the recovery, the login method. The point isn’t the paperwork, it’s the comparison, the gap between the wall you meant to build and the one the audit found standing. Next month you run the same sheet again and the drift jumps straight out, because you have a written yesterday to measure today against instead of a vague feeling.

Audit like the platform, not the owner

The mindset matters more than the checklist. When you read your own fleet, read it as the adversary, not as the proud owner. The owner sees ten careful accounts and pats himself on the back. The platform sees a pile of records and looks for the one thread that ties any two of them together. Assume the link is already there and go hunting for it, because the review that matters isn’t the flattering one you give yourself, it’s the suspicious one a detection system runs the moment any account draws a second look.

Fix what you find, gently

When the audit turns something up, fix it, but fix it calmly rather than in a panic. Revoke the stale sessions, close the forgotten devices, move a shared recovery off onto the right identity, one careful change at a time. A fleet that suddenly logs every account out at once and rewires all of its recovery in one frantic hour is its own kind of red flag, a burst of activity that looks nothing like ordinary use. Clean up the way a normal person tidies their own account, a little at a time, not the way an operator scrambles when the alarm goes off.

Audit on a cadence, not once

Do it on a schedule, because an audit isn’t a one time event, it’s a habit. Isolation drifts the moment you stop watching it: a new device here, a helper’s shortcut there, a proxy that aged out and rerouted an account without telling you. The fleets that survive aren’t the ones set up the most cleverly, they’re the ones read the most regularly. Put the audit on a cadence you’ll actually keep, and you catch the drift while it’s still one account instead of after it’s quietly become the whole fleet.

What a clean audit looks like

Put it together and the shape is calm rather than clever. Every account read from the inside the way the platform reads it, one consistent body and one consistent place per identity, no shared device across the fleet, no shared address, no shared recovery, no shared login method, stale sessions closed and the whole thing written down and run again on a cadence. It isn’t a product you buy in one click. It’s an hour with the security pages the accounts already give you for free, spent looking for the link you’d rather not find.

The honest limit

Keep it in proportion, because the audit shows you what the account is willing to show you, which is never everything the platform knows. A login history is a courtesy, not a confession, and a device list is a summary, not the whole file. A clean audit removes the mistakes you can actually see: the open sessions, the shared fields, the obvious contradictions, and that’s a real and specific win. It doesn’t remove the signals sitting one layer deeper than any settings page will print. Anyone telling you a tidy device list means an account is safe is reading you a comfort, not describing how detection really works.

I audit my own fleets exactly this way, every identity read from the inside on a cadence, the shared thread hunted down before a platform pulls it, and every stale session and drifting recovery closed the moment the sheet turns it up. I run Singapore mobile proxy and cloud phone farms myself, so the stack I point you at is the one I keep clean by reading it, not a guess.

For the full audit sheet, the tools I pair with this process, and more honest, tested guides on running a multi account fleet, head to the Multi Account Ops home page.

Get new guides and videos first — join the Telegram channel.

need infra for this today?