Is Dynalist currently down for anyone besides me? Itâs out-of-sync on all of my devices (I may have lost dataâŚ), and it fails to load quickly in ordinary browsers, too. Iâm seeing this for the first time since I started using Dynalist back in the summer.
Tested on various devices. No Internet connection speed issues at my end. The Dynalist status page says everything is 100%, but that is not the case here.
Itâs troubling when the top-right corner claims âsyncedâ, yet data are out-of-sync. What can be done? I was just about to purchase the annual subscription.
Iâm definitely seeing slowness but syncing is still happening. However itâs taking much longer than normal. I donât know if thatâs any comfort or not
Thanks. Iâve seen an improvement now too. Iâd echo the concerns of others though that status page doesnât reflect such drastic performance hits. Does it only measure total loss of service?
Thank you, Shida, I can see it slowly improving as well. But it can sometimes take several manual reloads to get to the current status of a list.
Whatâs particularly troubling to me is when the top-right corner of the webpage or the app claims Synced when, in fact, the data hasnât been synced. I was looking at the same list on various devices, all of them claimed Synced in the top-right corner, even after manual reloads, yet the list was different on every device.
If at least the webpage/app reported Waiting for Sync or something like that, this wouldnât be so disquieting. Hopefully, the reliability of the sync status can be improved in future.
(To that end, I would also welcome if the sync status were directly visible on mobile devices in the top-right corner, too, without our first having to tap the three-dot menu button to view the sync status. Thank you.)
The status page indeed only measures whether our service is reachable, not performance. Internally we have a few dashboards in the office that displays vital information about server performance, which we keep a close eye on as long as weâre awake. We also have things like email, text and phone calls setup for outages.
The impact of todayâs issue was mostly that requests were taking an abnormal amount of time to be processed. Iâm still in the middle of trying to fix things but at the worst, responses were taking an average of 10 seconds to be fulfilled, and individual requests sometimes up to 20-30 seconds.
Acknowledged. It can certainly be improved - right now âSyncedâ means any local changes has been pushed to the sync server, but not necessarily that the local view is fully up to date with remote. Originally it was done this way to avoid the annoyance of flashing sync symbols while they work.
Weâve certainly received enough feedback for the sync status on mobile - Still unsure what exactly to implement but thereâs definitely room for improvement.
Thank you, Shida, itâs comforting to know that the Synced status does reflect that the data have been successfully submitted to the server. However, as you can imagine, it is certainly confusing and disconcerting to be viewing the same list on various devices, both devices claiming Synced status, yet the lists being different. Briefly, I was in panic mode, fearing data loss.
After you resolved the server issues, the items eventually appeared, but there could still arise syncing conflicts, couldnât they, if I started editing a list, imagining it being âsyncedâ as the status claimed, even though there was a different âsyncedâ version on the server at the same time? If I continued editing the non-synced local version, wouldnât it later overwrite the version on the server (or vice versa), leading to some data loss/distortion eventually, especially if I edited the same list items on various devices without them being fully in-sync at all times? This can be worrisome.
As to the status indicator, I for one would welcome âtraffic lightsâ. GREEN = fully synced; ORANGE = saved; YELLOW = sync in progress; RED = syncing paused/failed. As to it potentially distracting users through flashing, perhaps it could be a user option whether the sync status should be displayed directly or behind a menu button, and whether the sync status should be indicated as text or as âtraffic lightsâ. I for one find the text-based sync statuses more distracting (more time-consuming to read) than color-based signals would be, but that may be just me. I imagine most of us would only ever see an alternation of green, orange & yellow in a color-based status indicator, and I for one wouldnât find that distracting. (In fact, I believe it would be a time-saver for me, even if only measured in milliseconds.)
After some tinkering (also caused some slowness in the process), I have located the problem.
Itâs a combination of our change to the real-time push system (using WebSockets) and Cloudflare. We used to send heartbeat messages every 30 seconds, which was recently changed to 60 seconds. It seems like Cloudflare terminates connections that doesnât send any data within 60 seconds. This meant a lot of Dynalist clients were constantly being disconnected from the real-time push system, and reverting to the old âwait and check for changesâ fallback loop, which caused significant server load when everyone does it at the same time.
I have changed the real time push system to send out heartbeats more often. This seems to have calmed down the storm and weâre resuming full capacity right now.
Thank you for that update and fix. And Iâve just set up annual instead of monthly payments for my renewal, coming up next week, because I trust you will get it running reliably in the long run.
(After half a year of using Dynalist, I canât imagine getting back to a âlife without Dynalistâ. And nope, Workflowy wouldnât be a full-fledged replacement for me.)
@Shida Unfortunately, Iâm still experiencing syncing issues. Itâs not as bad as a few days ago when I started this thread, but the Synced status in the mobile app still doesnât correspond to reality.
Earlier today, I made some edits in some of my lists in the Android mobile app. I made sure to wait for the Synced status to light up before I put the app into the background. (Yes, I had to tap the menu button manually to view the sync status â I wish it was permanently visible.)
When I later opened the same lists in Chrome on my desktop machine, only fragments of my edits from the mobile app were visible. For example, one of the words only appeared with its first few letters, and then was cut off. Some list items I added in the mobile app failed to appear on desktop completely. Refreshing on desktop made no difference. When I reopened the mobile Android app, the missing items were there. I made another manual refresh in the mobile Android app, and only then, the items also appeared on desktop.
I hope you can address these sync quality issues in future, because this can lead to serious data loss. Iâm afraid the current Synced status as displayed in the mobile app, is partly fictional â it really is no guarantee that the data have been successfully synced with the server. (I made those edits in the mobile app some 10 minutes ago, yet even after 10 minutes, they did not appear on desktop, until I made another manual refresh in the mobile app.)
Hmm thatâs weird. I canât think of any reason why that would happen as the mobile app uses the exact same code to sync as the desktop/web versions.
When you say you made a manual refresh of the app, what exactly did you do? Were you able to check the version history to verify that it only synced the moment you refreshed it?
I have a suspect that itâs due to the backgrounding of the app, and somehow reactivating it might be interfering with the timers behind syncing.
And just to make sure, the mobile app does say âSyncedâ instead of âSavedâ when itâs clear that it still havenât sent all the changes upstream, correct?
Yes, it was saying Synced, not just Saved. I always wait for Synced to appear, before putting the app into the background. (And itâs time-consuming also because you always first need to press the menu button to see the sync status.) This time, even waiting for Synced didnât help â although it was clearly saying Synced, the changes werenât visible on desktop. Not just in one list â in several of them. Iâll let you know if I encounter this issue again in future.
As to how I refresh in the app â thereâs a menu item for it in the mobile app. You press the three-dot menu button, and thereâs a Refresh option. Only using this caused the app to finally submit all changes to the server.
Yes, the version history confirms what Iâve been reporting. I added a word to a list, but only the first two letters of that word got saved to the server at 2:47 p.m. (CET). Then at 3:14 p.m., after I returned to the app and performed the manual refresh, the rest of the word got synced as well. It was similar with another list â it took from 2:44 p.m. to 3:13 p.m. until everything from the mobile app appeared in the desktop version, but only after I manually refreshed the list in the mobile app, after half an hour.
(Yep, I realize the app is just a wrapper for the web version, but thatâs how things are now. I sometimes see discrepancies on the same mobile device â when I open the same list in the app and in mobile Chrome.)
I see. The refresh option in the menu I believe just restarts the app (it does a page refresh instead of a full app restart). When the app starts up, it does a full sync with the server which is why it then sends everything.
Last question that I think could help with the investigation: Does it seem to happen more frequently when you make changes after resuming the app from background as opposed to starting the app from fresh? When starting the app fresh, you would see the splash screen for a short while and also a loader in the middle of the screen before your document appears. When resuming the app from background, you would see the last opened document almost immediately.
If you donât remember thatâs fine, Iâm just curious to know in the future if you can look out for it.
Thanks again for being so patient with the investigation!
No problem, I thank you for your help with this issue!
Iâm a heavy Dynalist user, so I pretty rarely start the app from fresh. Iâm pretty sure that the issues observed today occurred after my resuming the app from background, as I was certainly using Dynalist on that phone even prior to 2 p.m.
So, Iâll try to be more careful from now on, and when resuming the app from the background, Iâll try to do a manual refresh before making any edits, and then again a manual refresh after I make changes.
That can be annoying and time-consuming, but itâs better than data loss. It would really help if both the sync status and the refresh button were directly accessible in the app. (Without first having to tap the 3-dot menu button.) On the desktop, I always make sure to hit the F5 key to refresh Dynalist in Chrome before resuming work in it. (I never close Dynalist on desktop â the Chrome window with it is opened permanently on my desktop and notebook.)
This can be worrisome.
I imagine most of us would only ever see an alternation of green, orange & yellow in a color-based status indicator, and I for one wouldnât find that distracting. (In fact, I believe it would be a time-saver for me, even if only measured in milliseconds.) 
Itâs not as bad as a few days ago when I started this thread, but the Synced status in the mobile app still doesnât correspond to reality.
Iâm afraid the current Synced status as displayed in the mobile app, is partly fictional â it really is no guarantee that the data have been successfully synced with the server. (I made those edits in the mobile app some 10 minutes ago, yet even after 10 minutes, they did not appear on desktop, until I made another manual refresh in the mobile app.)
