Alpaca Paper Account Positions Wiped

Alpaca Account Troubleshooting
22

We hit this twice today (July 7) across three paper accounts, and we have fairly precise observations that might help Alpaca narrow it down.

Symptoms:
GET /v2/positions returned an empty (or partially rolled-back) list, and GET /v2/account reported portfolio_value collapsed to roughly cash–i.e. the account was being valued as if the positions didn’t exist. Cash was untouched throughout, and GET /v2/account/activities showed no activity records of any kind corresponding to the disappearances–no fills, no liquidations, no journals. The positions later reappeared on their own, intact, both times.

Time windows (UTC, July 7 2026):

  • ~14:10 – ~16:00 — all three accounts affected simultaneously. Positions API returned [], portfolio_value == cash to the cent. It recovered on its own by ~16:30.
  • ~20:15 – ~21:00 — hit again. This time the rollback was partial: positions opened that same day were still returned, while everything older was missing. So the positions looked “rolled back and replayed with only today’s activity.”

It kind of looked like a read-layer / replica issue rather than lost state for a few reasons:

  1. Dashboard vs API divergence: During the second window, the web dashboard showed all positions correctly while the trading API (same account, same time) returned the rolled-back book. Same account, two different answers depending on which surface we looked at.
  2. Per-account flapping within seconds. At 20:30 (± a few seconds), one of our accounts read as fully empty while another still returned exactly one position (that day’s buy)–consistent with requests landing on differently-stale replicas.
  3. A phantom short from a fill applied against the vanished book. One account received a sell of 9 shares of a ticker at 18:43 UTC (position existed and the fill is in the activities log). During the second window, /v2/positions showed that ticker at −9–the sell applied on top of the rolled-back (empty) book. When the state recovered at ~21:00, the ticker correctly netted to zero. So whatever serves /v2/positions was applying recent fills onto a stale snapshot.

Verified with raw HTTP calls (no SDK) to paper-api.alpaca.markets, so this doesn’t look like client-side caching.

The state appears to survive server-side–both windows self-recovered with everything intact, including correct netting of trades made during the outage. I’d hold off on resetting accounts; you’d likely lose your history for a problem that looks fixable. The bigger operational risk is anything automated reading the empty book as truth.

For Alpaca folks: we’re happy to provide exact request timestamps, account IDs, and our full observation logs if need be.

23

The bug is forgivable; the handling is the concern: Paper accounts exist so trading systems can be validated against the live platform’s behavior — ours is a fully automated system scheduled to go live in a few months, and this event executed real (simulated) orders into an emptied account and cost a full day of forensics and repair. Respectfully, we’d like an official acknowledgment with root cause, a commitment that paper-platform incidents appear on the status page like any other incident, and guidance on what account state is authoritative after a restore. Incident communication is part of broker due diligence — the silence says more than the bug did.