2Timer
← Back to 2Timer

2Timer Help

Practical guides for humans, with structure that is easy for AI systems to parse.

Repair and Recovery

Purpose

Explain when to use 2Timer’s diagnostics and repair tools, what each one changes, and how to recover safely without deleting more data than intended.

When to Use This Page

Use this page when:

  • the app is stuck on a white screen or stale shell after an update
  • a meet database seems corrupted or inconsistent locally
  • you need to inspect local storage use
  • you are deciding between app repair, meet purge, results reset, or full local deletion

The Main Recovery Paths

2Timer has several different recovery tools. They are not interchangeable.

Repair App

Use Repair App when the app shell itself is broken.

This is the right choice when:

  • the app will not load correctly
  • stale files appear to be cached after an update
  • navigation or shell behavior is broken across meets

What it clears:

  • service workers
  • Cache Storage
  • local storage
  • session storage

What it does not delete:

  • meet databases in IndexedDB

This is the safest first recovery step when the problem feels like a browser/app-cache problem rather than a meet-data problem.

Diagnostics page actions

The Diagnostics page also lets you inspect local browser storage for 2Timer.

Use it to:

  • view overall origin storage usage
  • inspect IndexedDB databases
  • inspect approximate table/store sizes
  • delete one entire local database
  • clear one table/store inside a local database

These tools are more advanced and more destructive than Repair App.

Meet purge tools

Use meet-level purge tools when the app shell is fine but the currently open meet needs selected data removed.

There are two main meet purge paths:

Delete All Local Data

Use Delete All Local Data only when you intentionally want a completely clean local reset for this browser profile on this device.

This removes:

  • every local 2Timer IndexedDB database
  • Cache Storage
  • service workers
  • local storage
  • session storage

This is the most destructive recovery option in the app.

Where to Find It

Open Diagnostics from the app shell navigation.

On that page you will see:

  • a storage summary
  • an IndexedDB inventory
  • per-database inspection details
  • the Repair App action
  • the Delete All Local Data action

Recommended Decision Order

When you are not sure which tool to use, use this order:

  1. Export a .2t backup first if the meet is still accessible.
  2. Try Repair App if the app shell is broken or stale.
  3. Use results-only reset if you need to re-import results but keep the meet structure.
  4. Use meet-level purge if you need to remove specific categories from one meet.
  5. Use database or table deletion from Diagnostics only when you understand the exact local target.
  6. Use Delete All Local Data only as a last resort or an intentional full wipe.

What the Diagnostics Page Shows

Storage summary

This is origin-wide browser storage for the 2Timer app, not just the currently open meet.

IndexedDB inventory

This shows:

  • meet databases
  • settings databases
  • test or E2E databases
  • other local IndexedDB databases tied to the app origin

For each database, the page can show:

  • approximate record counts
  • approximate bytes
  • per-store inspection rows

Clear table

The trash action on an individual store clears all rows in that one table/store inside the selected database.

Use this only when you know exactly which store you are clearing. It is not a normal operator workflow.

Delete database

This removes one local IndexedDB database from this browser.

For meet databases, that also removes the matching meet entry from the 2Timer settings meet list.

Common Recovery Scenarios

White screen after deploy or update

Use Repair App first.

This is the classic shell-cache problem and does not usually require meet-data deletion.

Current meet needs a clean re-score or re-import

Use Purging Results and Resetting State, not Delete All Local Data.

One meet database is beyond recovery locally

Delete that meet database from Diagnostics only after confirming you have the backup or truly want it gone locally.

Browser profile needs a completely fresh local start

Use Delete All Local Data only when that full wipe is intentional.

Confirmation Prompts

The destructive recovery tools use typed confirmation phrases such as:

  • DELETE
  • DELETE ALL

These exist to slow down high-risk actions. Treat them seriously.

Common Mistakes

  • using meet purge when the real problem is stale app cache
  • using Delete All Local Data when only one meet needs cleanup
  • clearing an IndexedDB store without understanding what it contains
  • skipping backup export before destructive recovery

Verification Checklist

  • You chose the smallest recovery action that solves the problem.
  • You exported a .2t backup first when possible.
  • You understand whether the action affects only the app shell, one meet, or all local data.
  • After repair or deletion, the app reloads cleanly.
  • The intended meet data is still present, unless you deliberately removed it.

Related Pages

Metadata

  • Last Updated: 2026-04-18
  • Version: 0.1
  • Status: Active