Changelog v1.14.1

For Storage Nodes

Audit and Suspension Score Warning
In the last release, we introduced an audit and suspension score overview on the storage node dashboard. The yellow warning sign will now be shown for any score lower than 95%. Special thanks to @BrightSilence

Held Returned
The storage node payout dashboard is now showing held returned for previous payouts. It will display the 50% held returned in month 16 as well as 100% held returned after graceful exit.

Dashboard Used Space Fix
After reducing allocated space below used space the storage node dashboard was showing incorrect numbers. The dashboard was assuming that a negative free space value must be a bug and was showing (allocated space - free disk space) instead. That adjustment was a workaround from the old days. In the meantime, we had a few fixes on the backend side. I believe the workaround is not needed anymore. The dashboard should show the correct used space values now. Please let us know if you still see wrong numbers on the storage node dashboard.

Windows Updater Fix
The windows updater v1.12.3 and v1.13.1 are able to download a new version but they will fail to restart the storage node and more important they will fail to restart themself. Even after a manual storage node update when the dashboard is showing the latest version the storage node updater might still fail to update itself. Please check the logfile for the storage node updater C:\Program Files\Storj\Storage Node\storagenode-updater.log. Make sure to look into the updater log and not the storage node log. In the logfile search for the last Running on version. v1.13.3 or v1.14.1 is good. If you are running an old storage node updater please restart the updater. If that still doesn’t fix it please replace the updater with the version from github and restart the updater one last time.

Linux vs Windows Updater
We did some progress on the Linux updater. We still have a few more issues to fix before we can release it. One problem was the file extension on our github page. The windows binaries ended with but the linux binaries don’t. To unify the windows and linux updater we renamed all files on our github page into .zip . The file names inside the zip archive haven’t changed. We don’t expect any issues on the storage node side but this change might break identity and uplink download links. If you notice a wrong link please let us know.

For Customers

Multiple Project Support
Each project comes with 50 GB storage space and 50 GB download traffic limit. Each project also comes with its own separate API keys. And last but not least projects will be listed in the invoice.
Please contact support if you need more than 10 projects.


Could we please finally get rid of loading screen on storage node dashboards?


I haven’t seen anything around that topic in the commit history or in the sprint. All I can do is call @viktor

What’s wrong with the loading screen?

It loads too much.

Congratulations on having 20 characters minimum to post.

1 Like

There was a lot of discussion and feedback on the loading screen when it was introduced, the general concensus was people didn’t like it and wanted the previous method without any loading screen.

The new screen loading introduced an additional delay in actually showing the data on screen compared to taking a split second to see the data.

Actually in the current/latest version of StorJ my dashboard node takes a good 15~ seconds sitting on the loading screen to show the main dashboard page. This used to take half a second before loading screen was introduced and with the loading screen introduction originally it took 2 to 3 seconds. Unsure why it’s now taking 15~ seconds.

1 Like

I think the correct person to tag for this is @NikolaiYurchenko


Hey, we have this loader task in our backlog, but as soon as it’s low priority we’ll not implement it in next few weeks. For now first priority is multinode dashboard


Even though I understand it is low priority compared to other problems, it is a rather poor choice to tell SNOs “we’re going to change it in the nearest future. Please wait for changes, your feedbacks are really important to us.” when the nearest future doesn’t even have a date and might not even be anytime soon. Doesn’t make SNOs feel like the feedback was very important. (Of course adding the loading screen in the first place was due to feedback from the SNOs and a rather low priority feature as well. I’m just exaggerating a bit. Not every SNO reads everything or has been around this long)


We’re reading feedbacks and implement requests from community. This one (with loader) will be also implemented, but not in that sprint. By the way multinode dashboard is also a community request


Then how about a quick workaround, at least for a web dashboard? You could modify the “loading-screen” class height to match header height and adjust the spinner size accordingly. It takes a minute and will be a great QoL improvement.


And one that will have a much bigger advantage for people operating more than one node.
I for one agree with that priority.

In the future it may help to just state that it’s on the backlog and will be picked up at some point. I think it’s completely fair to let other priorities take precedence though.


Thanks for this new release!

I understand there is no change about Disqualification for downtime. Could you confirm?

I plan to move to a new place (new home) next week (the new house is just 10 minutes from my current place).
Should I be worried about being disqualified for downtime? Or is it OK so far?


The downtime measurement is enabled. Suspension or disqualification is not yet enabled. You should try to minimize downtime because it will show up in your history for 30 days. If we enable suspension in 21 days you might get suspended. Disqualification shouldn’t be a problem because worst case you would just get suspended for up to 30 days but if you don’t collect new downtime you would get unsuspended.


Has minimal allowed version been rolled back? I think it said 1.12 when I last checked, now it’s 1.9, or did I mix something up?

Yes. Your observation is correct :slight_smile:

1 Like

Thanks for your reply, it’s quite clear :slight_smile:

I know that this request has already been discussed but I think it would be very appreciated to be noticed a little bit before enabling the disqualification/suspension for downtime.

I don’t know the real constraints on Storj Labs teams.
Do you think it could be possible?

You can already see the number using the earnings calculator.

For the first 30 days this score will show 100% though. I’m not entirely sure when those first 30 days are over. My nodes still show 100% everywhere. But I’ve also had barely any down time. The reason for this is that the satellites don’t want to punish nodes within the first 30 days, because not enough data is known yet. It should of course still show the actual score and just omit any punishments, but that’s not currently how it’s implemented. Either way, you can monitor the uptime there until it’s shown on the dashboard (which I’m sure will be soon as well).

By the way, is there an official topic or article that explains how Disqualification and Suspension work?
We can find information spread out around the forum but it would be more convenient and easier to understand if we had an article on

What do you think?