Offline and reconnect

What works without a connection, what does not, how to tell whether your changes have reached the server, and what a pending change depends on.

Available Updated 2026-09-24

What works offline

Once the app is loaded, supported work backed by the local database includes:

  • Reading every issue, project and label in your local replica
  • Creating, editing and deleting issues and projects
  • Changing status, priority, assignee, labels, dates
  • Filtering and local issue searching, including Team scope on the Search page
  • Copying a context bundle — using available local material, with incomplete discussion disclosed

What does not

  • Company issue search — sends queries and filters to Orneos; switch to Team scope for available local issue results.
  • Vault full-text search and online snippets — local title matches can remain, but page-body search needs the server.
  • Vault — page content is not stored locally yet. This is the big one and it is a known gap.
  • Insights and AI drafting — both call a model provider.
  • Comments on issues you have never opened — they load on demand, so there is nothing local to read.
  • Issue reference numbers — the server assigns them. An issue created offline is fully usable; its number arrives when you reconnect.
  • Invitations and membership changes — authorisation is server-side.

While you are offline

Supported local edits can continue while disconnected. The interface may show an edit before its local write and queue append finish; check pending and failed changes before discarding storage.

Once queue writes complete, those entries can survive a refresh and a browser restart. Interrupting a save before it finishes can still lose in-flight work. It lives in the same durable local storage as your data, not in memory.

When you reconnect

Reconnection coordinates two processes; do not rely on a fixed push-before-pull order:

Your queued changes are pushed. The worker drains the queue oldest-first. If the server has moved on for a record, the change is re-applied against the newer version and retried. A change that is permanently rejected — no longer authorised, say — is marked failed and surfaced rather than retried forever.

Missed changes are pulled. For each team, the client asks for everything after the last position it durably applied, and replays it. If the gap is too large to replay, it rebuilds that team’s data from scratch instead of guessing.

Knowing whether your work is safe

This is the question that actually matters, so:

  1. Be online. The queue only drains with a connection.
  2. Check both pending and failed changes. Wait for queued work to settle and resolve any failures. An empty pending count alone does not establish that rejected work reached the server.
  3. Confirm important work reached the server before signing out or clearing storage. Keep a separate copy if you cannot resolve a failure.

Three ways to lose unsent work

A queued change lives in your browser’s storage until the server accepts it. It does not survive:

  • Signing out, which destroys the local replica by design. See Companies and teams.
  • Clearing site data or using “clear cookies and site data” for the origin.
  • Browser storage eviction, which can happen under disk pressure — and private-session storage can be discarded when that session closes.

Reconnect and let the queue drain before doing any of these.

A detail about multiple teams

When connected, the worker attempts queued changes across teams, using each change’s owning team for server authorization. You do not need to visit every team to start its drain. Rejected or failed changes still require attention; check pending and failed states before clearing storage or signing out.

Offline launch limitation

Refreshing or opening the app while offline may fail to load the application shell. This is separate from the locally stored data and queue: a failed page load does not itself erase them. Reconnect to open the app again, and avoid clearing storage. Installing the app does not remove this known limitation.

Testing it yourself

Worth doing once, because it teaches you the boundaries faster than reading about them:

  1. Load the app and let it settle.
  2. Turn off your network (or use your browser’s offline mode).
  3. Create an issue, change a status, edit a description.
  4. Optionally refresh while still offline. The app may fail to load because offline document navigation remains unverified. Reconnect if needed; do not clear storage. Confirm your locally saved edits once the app opens again.
  5. Reconnect and watch the pending indicator clear.

Then try step 4 with a Vault page open and see the difference.

Something here wrong, missing or out of date? Tell us at support@orneos.com — corrections to these pages are welcome and we would rather hear it than have you work around it.