Your training log is only as durable as the incentive to keep it.

The log came back empty

The log came back empty after an overnight auto-update. An update to Strong's v6 release, roughly 150 logged workouts no longer there, no rollback, no local copy on the phone to fall back to. Reddit thread (r/strongapp, ~1 year ago) reports Strong 6.0 auto-update deleted workouts, dropping count from 1176 to about 150 remaining ([source](https://www.reddit.com/r/strongapp/comments/1klb46k/updated_to_60_and_150_of_my_workouts_were_deleted/))

The replies ran the usual course. Sorry, that's brutal. Did you have an export? Have you emailed support. Somebody posted a link to a rival app's import page, which is its own kind of answer.

What the thread never got to is why this keeps landing on lifting logs specifically. Across apps. Across years. A free notes app from 2014 will still hand back a document you typed on a phone that no longer exists, and a training log built in 2021 sits one bad migration away from nothing.

Retention-shaped storage

Durability has no growth metric attached to it. That's the whole thing.

Sit in a roadmap review at any subscription-funded tracker. Migration-safety work competes against onboarding polish, a social feed, an exercise library refresh, a paywall test. Onboarding polish moves a number somebody reports on Monday. A migration script that never loses a row moves nothing anybody reports, right up until the week it does, and then it's a support cost. Export tooling sits lower still, because the honest description of a great export flow is a well-lit exit.

So the deletion isn't a defect in the code. It's a defect in what the code gets funded to do. Call it retention-shaped storage: every storage decision made by people whose success is measured in users not leaving, and none of them made in bad faith.

Calling it a bug lets everyone off the hook

Two framings dominate whenever this happens, and both are wrong in the same direction.

The first is that it's a bug. Bad luck, edge case in a schema migration, patch inbound. Bugs are one-offs, and this isn't one. Data loss on update is a recurring event in this category, reported year after year, on different apps, by lifters who did nothing unusual except let a phone update overnight.

The second is that the lifter should have exported. That advice sounds responsible and it fails on contact. Most lifters don't export until they've already lost something. And a CSV sitting in Files isn't a restore path. Nothing reads it back into the app it came from, so what you're holding is a spreadsheet with your training in it.

Both framings quietly agree that the storage layer is fine and the humans around it need to be more careful.

The category leaves a trail

You can read this pattern off the market without a single leaked incident report.

Start with import flows. Import-from-a-rival paths are a standing feature across the major trackers, and switching guides are a permanent content genre around them Hevy's import page states it only allows importing CSVs from the Strong app. ([source](https://help.hevyapp.com/hc/en-us/articles/38001424401943-How-to-Import-Strong-App-CSV-Files-and-Export-Your-Data-in-Hevy)). Import tooling exists because stranded logs exist in volume.

Then look at what lifters type into a search box: recovery queries for deleted workouts, whether history transfers between apps, whether old sessions can be restored at all. Search demand for recovery is search demand manufactured by loss.

Third, the review corpora for every large tracker carry the same complaint shape at the same low frequency. Sets missing after an update. History not restoring on a new phone. A year that simply isn't there. Low frequency, high severity, and invisible on any dashboard measuring weekly actives.

Four years of RPE isn't something you remember

Take a lifter five years in. 5/3/1 for the first two, an RP-style hypertrophy block after that, a meet somewhere in the middle, and a log that never had a gap longer than a deload.

What's gone when 2021 through 2023 disappears isn't the headline numbers. Anybody who pulled 500 remembers pulling 500. What's gone is the density underneath it: how many sessions at RPE 8 stacked up before the top set stopped moving, which accessory rotation was running the month the elbow started talking, what the last two peaks looked like at the same bodyweight, how long a deload actually needed to be before the bar felt fast again.

That's an N=1 dataset with a five-year collection period and no mechanism for a second run. You can train the lift back inside a year. You can't collect 2022 twice.

A lifting log is an experiment with a five-year collection period and no possibility of a rerun.

Three questions that predict whether a log survives

Ten minutes with the app already on your phone will tell you most of what you need.

One: can you produce a structured export right now, at whatever tier you're on, without emailing anybody? If export is a paid feature or a support ticket, that's a decision somebody made about your exit, and it's the loudest signal in the whole evaluation.

Two: if the phone in your pocket dies tonight, where does the log live? On-device and iCloud-only are different answers with one shared failure mode, which is that a restore you don't control is a restore that can fail quietly.

Three: what happens to history when payment lapses? Readable, or hostage? A tracker that dims your charts at the end of a billing cycle has already told you which side of the incentive it sits on.

How Platepusher answers those three

Platepusher answers all three the same way for every lifter on it, and the answers don't move when billing does.

The log lives in a Postgres database we run. Not on the phone, not in your iCloud. That's a real trade and it's worth stating plainly: we know your email from Sign In with Apple or Google, we get crash reports, and we count anonymous feature-usage events you can switch off in Settings. What we can't do is read your workouts. Row Level Security enforces isolation at the database layer, so cross-user reads fail even when the app layer has a bug in it. What the trade buys is a log that survives a dead phone, because backups and sync are server-side, and an offline cache that rebuilds in seconds in a basement gym with no signal. An iCloud-only tracker can't help you on the day iCloud loses the file. We can.

Export is CSV, in Strong's exact column shape, free at every tier including the free one. It exists for the case where you leave.

On price: $4.99 monthly, $29.99 yearly, or $99.99 once. Same Pro feature set across all three, lifetime is the headline tier, and existing buyers never get ratcheted. Full history, import and export sit outside the paywall rather than behind it, which is the only version of this claim that means anything.

What we're watching next

Two things worth tracking over the next year. Whether any tracker publishes a real durability commitment, a restore window, a backup posture, a retention policy stated in language a lifter can check, because nobody does today and the first one to do it sets the floor for everybody else. And whether import tooling keeps getting better, since it's currently the only place in the category where the incentives happen to point toward your data being portable.

Neither one changes the underlying math. The next log that vanishes after an update won't be a bug either.