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.
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 in Spotlight and on the Search page
- Copying a context bundle — using available local material, with incomplete discussion disclosed
What does not
- Organization issue search — sends queries and filters to Orneos. Offline, Spotlight searches the active team instead and the Search page asks you to switch to Team scope for available local 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.
When only the server was unavailable
Your network can stay up while Orneos’s server is briefly unreachable, for example during a restart. The header then shows Reconnecting with a pending count. Changes you make in the meantime, including new ones, wait on this device; they are not retried against a server that cannot be reached.
When the app’s live connection to the server is re-established, queued changes resume automatically, without a reload. Reconnect attempts back off, so this can take a short while after the server is back. If the header still shows Reconnecting well after Orneos is reachable again, reload, and please report it.
Knowing whether your work is safe
This is the question that actually matters, so:
- Be online. The queue only drains with a connection.
- Check for pending and failed changes in the sync status at the bottom of the sidebar, just above the ? button (see below). Wait for queued work to settle and resolve any failures. An empty pending count alone does not establish that rejected work reached the server.
- Confirm important work reached the server before signing out or clearing storage. Keep a separate copy if you cannot resolve a failure.
Reading the sync status
The sync status sits at the bottom of the sidebar, just above the ? button, and describes this browser. It stays empty while everything is in order and appears only when something needs your attention. With the sidebar expanded it shows a coloured dot and a short label; with the sidebar collapsed it shows only the dot. Hover over either, or focus it with the keyboard, to read the full explanation.
| Status | What it means |
|---|---|
| Connecting… | Your workspace is still loading. Shown only when loading takes more than about two seconds. |
| Offline · N pending | Your browser reports no connection. N changes are saved on this device and wait for the connection to return. If the workspace was still loading, it finishes once you are back online. |
| Reconnecting · N pending | Your browser is online but the server cannot be reached. N changes wait on this device. |
| Syncing… | Queued changes are being sent now. Shown only when sending takes more than about two seconds. |
| N pending | N changes have not yet been accepted by the server, for example while a retry is waiting. Shown only when this lasts more than about two seconds. |
| N not saved | N changes in the current team were rejected by the server and will not be retried. |
| (nothing shown) | Nothing is waiting to sync from this device and nothing is rejected in the current team. |
Most saves reach the server within a moment, so Connecting…, Syncing… and N pending are held back briefly to avoid flashing on every load or edit. Offline, reconnecting and not-saved states appear immediately. Once the status is showing, it stays until nothing is left to sync, so it does not disappear while queued changes are still being sent. Screen readers hear each change, and hear when it clears.
The pending count covers queued changes for every team on this device. The not-saved count covers only the team you are viewing. An empty status describes what this browser still has to send; it does not prove that a colleague has already received a change, and it does not show whether incoming updates are live.
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
If a save reports that your workspace is not ready or has changed, keep your text, let the team finish loading, and reopen the item in its original team before retrying. A refusal is not a queued change.
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:
- Load the app and let it settle.
- Turn off your network (or use your browser’s offline mode).
- Create an issue, change a status, edit a description.
- 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.
- Reconnect and watch the sync status above the ? button go from Offline · N pending to empty. A larger queue may show Syncing… briefly on the way.
Then try step 4 with a Vault page open and see the difference.
Related
- How sync works
- Local data and storage
- Troubleshooting — when the queue does not drain.
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.