Change UI to reflect 1-12 hours between background syncs

Feature Requests Password Manager
,
1

Hello, I really like bitwarden and I have been using it for many years (6? 7? it was before COVID). I recommend it to all kinds of people. But recently I finally found out about this issue I think has been going on for a long time. It either should be fixed or at least mitigated.

I realized the the desktop firefox addon is extremely lazy about syncing. Once I searched for the issue I found many people complaining about it for ages.

many hours between sync

Here is a screenshot I took where the vault last synced itself 9:39 am. Whereas the time was 9:31 pm. 12 hours!! I went to look because I was on a different device searching for a credential I had created in the morning but unable to find it. I would understand waiting if there was nothing to to be done, but the fact it behaves this way even when there is information just sitting on the local device.. isn’t that a bit nuts?

12 hours no sync
12 hours no sync935Ă—492 55.7 KB

It syncs fine when I ask it to, and it does background sync by itself eventually but I have no idea what the schedule is. Most times I look, I’d say it has synced in the past 1-4 hours.

At home I use linux and am on a shaky network of my own amateur creation. But at work, I have a corporate windows PC and a network run by professionals. I have been checking the sync there and it is the same, 1-4 hours or so. As at home, it does eventually sync itself. In neither case if BW being totally blocked by a firewall or something right?

I’ve read that it’s supposed to sync every 30 minutes and honestly that is still completely unacceptable when there is local information just sitting around. Checking for remote changes to pull, sure, OK. But when the local app knows it has the only copy of something, why can’t it initiate the exchange? A person can only create/edit logins so fast, it’s not as though I can DDOS your servers by making or updating items.

just to show I wasn't doing something funny with the clock here is immediately after syncing
just to show I wasn't doing something funny with the clock here is immediately after syncing673Ă—380 54.2 KB

how this has caused me a lot of grief

Having learned of this laziness, it explains some very frustrating technical problems I have had over the years setting up computers and home networking. I can’t tell you how many times I went looking for a root password, ssh key, configuration details etc that I know I stored in the password manager, but was unable to find it, or what I did find was incomplete/wrong.

In one case I even downloaded the whole vault, converted to a spreadsheet and combed through entries trying to determine what crazy unguessable name I had given to the entry where I stored the root login creds to a Wireless Access Point. [1] Now that I know about this laziness, I think what probably happened is it saved locally only then I disconnected the network, and eventually restarted the device, or might have been working on a secondary device for convenience which got turned off and put away. At any rate I had every reason to believe the creds were pushed to the cloud service but in fact they were just created in an ephemeral and unreliable local state.

Just sharing this one of various times when I have had issues finding credentials, in hindsight they all involved situations where I would have saved a credential then soon powered off, disconnected, reinstall the local OS, whatever. But the credential which appeared to be saved was only saved locally. I am a very bad person who just leaves my main computer running 100% of the time so for most logins, it will eventually get synced. But for people who don’t do that, it must cause so much havoc. Since there is years of threads asking for better sync, it seems that it is not happening. Here are my suggestions to mitigate it:

if it isn’t saved to the cloud immediately, feedback should not mislead

make it less tortuous to verify and sync manually

Since I guess the user is expected to manually verify each and every login has been synced if they want to keep it, please at least make it easier to determine and to perform?

  • make it easier to know when the last sync was. I would like this information displayed all the time, even in small faint text or something
  • put the manual sync button in a convenient place. You have to click 4 times to get from it the login item view. (BTW to count I went to the the sync page, it is currently 00:35 EST and last vault sync was 9:32pm = 4 hours.. when I took the above screenshot.) And another 4 to get back to viewing or editing an item. I am supposed to do this every time?

Here is how I personally would like

easy to see when was last sync and initiate one manually
easy to see when was last sync and initiate one manually533Ă—203 19.8 KB

Can you add a keyboard shortcut to sync? Then it won’t clutter the interface (though the temporary nature of doing anything in the application really should be communicated strongly to the user)

Differentiate unsynced items

Could also highlight unsynced items:

not a very god mockup
not a very god mockup692Ă—230 40.4 KB

current versions

Firefox Developer 139.0b9 with Bitwarden extension 2025.4.0

Since I took the screenshot at the top, 9:32pm, the vault still hasn’t synced itself. Current time = 1:37am

Can I access a log of syncing or is babysitting the only option to find out?

  1. Footnote: I had installed 3rd party open source firmware on my Access Point and one of the compatibility issues is that it breaks the factory reset. So if you can’t login the only way to potentially gain access back is something to do with soldering the circuit board! Of course since I am a devoted user of a password manager I knew I’d be safe from that kind of error—NOT. Now the $80 WAP I splurged on is just a sad paperweight and my wifi still sucks until I can afford to buy a new one which will be.. never. ↩︎

2

Hey there, thanks for your patience! The team isolated an issue with background timers and the fix will go out soon.

3

Besides background syncing of the entire vault, my understanding is that Bitwarden does use a push mechanism (WebSockets) to initiate an immediate sync from the device in which a change was saved:

 

Please note that when “Live Sync” of individually updated items occurs, the last sync timestamp in Settings > Vault is not updated, so in part, you may have been mislead by this.

I don’t know whether the “issue” referenced by @dwbit would have impacted the “Live Sync” functionality, as well. FWIW, it seems to be working fine on my end (in Chrome, extension version 2025.4.0).

4

thanks @dwbit that’s good to know. :slight_smile:

But doesn’t it make sense to build in a bit of safety for those cases when the system doesn’t work perfectly? there are all kinds of ways to go wrong, not even all of them under your control. For example the user creates an item then the internet connection goes out before it was sent.

When I searched for this problem I found all kinds of troubles over the years. One way or another, there can always be sync issues. The extension shouldn’t falsely reassure me the data is saved until it actually is.

5

I’m not convinced that any such false reassurances are actually provided in the current implementation.

6

The situation that led me to make this post was that I created an account at night on my computer, then in the morning I wanted to log in from my phone. Both devices were on wifi all night. But when I when into BW mobile I couldn’t find the new item even when manually syncing (from the mobile). I had to go back to my computer and manually sync from there first to get it into the cloud. Good thing it was convenient to access… what if I turned my computer off then left home expecting to be able to access credentials? I’d be outta luck.

This is not infrequent, it happens now and again that I have to manually sync to get things on another device. I don’t know what the max time is.

Short of wearing a go-pro whenever I interact with the password manager and livestreaming that, how could I prove anything to you about it? To properly test you’d what to mechanize it somehow rather than relying on random, incomplete user reports like this one. Which is why I am not making a report about the syncing behaviour: I have no useful debugs or logs or anything. Useless on that front.

Oh my, so there is no way to know if things have actually synced to the server? Other than what, individually searching for each and every one of them on another device? That’s even worse! :frowning: I think the idea of highlighting unsynced entries makes even more sense.

What does syncing the vault even mean then? (Whatever it is supposed to be doing, it still is showing 9:32:33 pm yesterday just like when I posted this with local time being 10:00pm.. more than 24 hours. So whatever it is, it’s not getting done.)

On this page Sync your Vault | Bitwarden it says:

Items owned by you in the web vault will always remain in-sync. Items owned by an organization will sync across users and client applications every 30 minutes.

Other Bitwarden apps (browser extensions, mobile apps, desktop apps, and CLI) will sync automatically on login, and regularly when unlocked.

So even by design you might have a window of up to 30 minutes where items are not synced. And however long “regular” is. You could easily create or update an item then turn off the device 10 minutes later.

The same page identified >2 known issues that cause syncing difficulties: “Mismatched timestamp” and “VPN or ad blocker interference”. Does the user get any notification they are subject to these, or do you have to figure it out after the fact when you have a big problem?

If it tells me it’s saved, I want to trust that. If it’s not saved, that’s OK. I just want to know.

If you want to argue with the BW devs that their documentation is wrong, that’s probably a different thread.

it seems to be working fine on my end

Sometimes it works and sometimes it doesn’t. I can’t reliably reproduce.
I’m not asking for the application to function flawlessly at all times. But to provide feedback so you can know if it is safe to log out.

Which is why I am primarily asking for some sort of indication of status rather than a perfect application that never has any hiccups. :slight_smile:

7

Recently, there have been some bugs related to synchronization, but I believe fixes for the ones I know about have already been released. Perhaps there has been a regression, or a new bug has appeared. Bugs should be reported on GitHub (click “New Issue”).

8

Thanks for the info!

I am not making a bug report. I am making a feature request. The application should accurately report its status and notify users of unsynced data.

The current bugs can be fixed, but new ones will pop up. You can look through the history over the years and find many times when there were sync issues.

For mission critical applications, it is only arrogance to avoid putting in failsafes. Nobody’s work is perfect! Not mine not yours.

9

My understanding is that the notification “Item saved” is initiated by the server upon successful update of the cloud database; there are alternative messages that indicate errors in saving the updated vault item.

If you have evidence that the Web Vault is not updated after the “Item saved” message has been displayed, I would like to see it (or at least have get your confirmation that you have observed such behavior).

I think it would be challenging to poll each logged-in device to verify that the cloud database update has propagated to all Bitwarden client instances before displaying the success message, and attempting to do so would certainly introduce a noticeable delay in the display of the message.

 

For the record, the Bitwarden code is not my work. I am a Bitwarden customer, same as you.

10

“Unsynced data” could mean two things uploading or downloading. I presume you refer to uploading changes to the cloud.

Bitwarden does not have the ability to make changes while offline that would need to be sync’ed later (there is a FR for it, though – go vote for it). When a change is made and the save button is clicked, it immediately uploads the changes to the cloud. “Item Saved” is supposed to be the indication that this all happened correctly. If you are finding that something is not in a freshly logged into web vault (https://vault.bitwarden.com) after having been reported as “Item Saved”, that should become the topic of a bug report (click the green new issue button). As such, “unsynced local items” is not even a concept.

The “last sync” time is when changes were downloaded to your client. As @dwbit indicates, they are adjusting these timers to fix bugs and make it unnecessary for the sync button to be front-and-center.

That said, @bigbill does have a good thought. Perhaps the clients ought to display a warning message “working offline” that includes a “sync now” button if the client has not synced in the past N-minutes.

11

In my experience (as I noted above), the “last sync” timestamp is not updated when individual items are updated via WebSockets push (“Live Sync”), only when the full vault is synced (on demand, or on unlock, or by an automatic background process).

The one improvement that would make sense to me (other than fixing any remaining bugs) would be to update the “last sync” timestamp also when there is a push update via WebSockets (or have a separate timestamp for such events).

12

Presuming that the push included a vault timestamp/checksum to validate there are no lingering downloads, that certainly does make sense.

On the other hand, for uploads (the greater concern on this topic), I fully expect “item saved” to be confirmation that the particular update was completely updated and confirmed by the server, largely mooting the value of an upload timestamp.

13

I wasn’t suggesting an upload timestamp, only that the clients that receive (in effect, download) the live-synced updates should timestamp the arrival of such updates.

1 Like
14

Download of remote data to the client is less critical because whatever is stored remotely is safe.

I never ever use the web vault. I mostly use the FF extension and android app. I guess if I was going to report a sync bug it would be useful to check the web vault to verify where the problem is… but I am not reporting a sync bug. I am suggesting a failsafe behaviour in anticipation of sync bugs.

It would be cool if some dev or other informed person could chime in to say if this is actually what’s supposed to trigger the “item saved”? I think, based on my experience, that the “item saved” is displayed regardless after you submit the form. I do not think that there is any communication with the server happening prior to displaying that. When I am slow/flakey internet connections, I notice no delay as would be expected if actually communicating with remote.

agree

15

I am no dev, but I believe that this is the relevant section of the code:

 

Line 334 is responsible for displaying the success toast message (“Item saved”).

Line 339 emits an “event” which signals (to event listeners) that the cipher was saved successfully. For example, the event listener onCipherSaved is responsible for changing the screen from “Edit” mode to “View” mode.

I (or somebody else) would have to dig into the details to figure out exactly when/where the updated item data are actually transmitted to the server (and from there, pushed to the other clients), but it seems likely that this happens in lines 324–327.*

I would suggest that the next time you have a slow internet connection, open up you Web Vault to check whether you see updates take effect there when you see the “Item saved” message.

 

*Here is my interpretation of the code (which should be taken with a grain of salt, as I am not a TypeScript programmer): I believe that the saveCipher() method called on Line 324 is the method defined starting at Line 29 of default-cipher-form.service.ts, and that saving an updated vault item in an individual vault results in a call to the updateWithServer() method on Line 67. I further believe that the updateWithServer() method called here is the method defined starting at Line 793 of cipher.service.ts; on Line 802 of the updateWithServer() method, there is a call to a method named putCipher(), which appears to be defined on Lines 491–494 of api.service.ts. The putCipher() is what updates the server database, using a standard HTTP PUT request. Thus, it seems that the server is updated before the success message is displayed.