Standard Notes is a Better Project than Braindump

released braindump to the world last year to much fanfare. After the initial excitement from being on HN died down, and the PR’s stopped rolling in, it became a personal project once again with very few users. Over the last few weeks I have made several attempts to fix the spaghetti mess that is the current code base by refactoring the current Flask implementation, then rewriting it completely in Django, and even started a branch to investigate rewriting the whole app in PHP using Laravel. Other commitments took precedence and Braindump remains in a fairly usable but not that special state.

Today on HN I read about a new project called Standard Notes which is the most exciting note related project that I have seen in a long time. It solves so many of the problems around cross platform compatibility that plague many other note tools. In addition its goals are to create a standard file format for simple, secure, and durable notes. Even more it has already created a platform, an ecosystem, that allows anyone to come and create additional applications, plugins, and use cases for notes.

These are some of the problems that I set out to tackle when I started braindump. After reading about Standard Notes, and using it for a few hours, I have decided that my time would be better spent contributing to that project instead of continuing to work on Braindump.

Working on Braindump has been amazing. I learned a ton, became a better programmer, and most of all had a lot of fun. I want to thank everyone who tried it, provided feedback, and sent patches. The source code for braindump will remain on GitHub but I would encourage you to try and contribute to the Standard Notes project along with me.


100% Uptime*

I have been a customer of Vultr on and off since March 2015. I have been running a VPS (Virtual Private Server) server on one platform or another since 2011 and I spent some time working in operations for a large VPS provider. In addition I briefly started my own VPS service last year. My experience with Vultr has been mostly good. Their support is responsive, service is mostly stable, and aside from a few expected hiccups related to abuse on a shared host, things have been great. Recently while browsing their home page I noticed that they offer a 100% uptime SLA.

I was pretty intrigued by this. My previous experience has led me to believe that achieving a true 100% SLA is practically impossible. Hosting is a frustrating and difficult business where something will always go wrong and there are way too many variables beyond any one companies control to be able to promise 100% uptime. So I thought to myself, what is Vultr doing that no one else can?

Well, based on my most recent interaction with their account management team, the short answer is “Nothing”. As far as I can tell this 100% Uptime* guarantee is just a marketing ploy that is intended to make Vultr look like a great value without actually being one in the same way that mail in rebates (remember those?) made things seem very cheap until you had to actually go through the process of sending in the rebate and hoping that the return check actually arrived.

Recently I got the following email from Vultr:

We have detected a system issue with the node hosting the instances listed above. Our engineering team applied system updates and scheduled a brief maintenance window to perform a node restart. Date and Time: Jan-13-2017 11:00 UTC (Jan-13-2017 03:00 Local Time) Please note: This event will reboot your affected instances. Your data and configurations will not be affected by the reboot.

There is nothing surprising here. If you have had a VPS turned on for more than 90 days from pretty much any VPS provider in the world you have probably received a very similar email. This seemed like a great opportunity to put their 100% uptime SLA to the test. The server in question runs about a dozen websites served by Apache, MySQL, and Redis. When a server reboots most of these services come back online thanks to systemd without any user intervention. However, I always like to double check that everything is up and running after a reboot so this means that I needed to be awake at 3AM to check to make sure that the server was in good shape.

The total downtime was less than 5 minutes (awesome!) and everything came back online without incident (double awesome!). According to their SLA chart I would be eligible for 12 hours of credit. I opened a ticket (on Saturday morning) and asked how the SLA process worked. I was informed that this question had to be answered by a member of the account management team and they would get back to me on Monday. No worries, totally get that, I thanked the support engineer for their time and waited patiently until Monday.

This morning I get the following email from their account management team:

If you experience any disruption in service that is not scheduled maintenance you would have to open a ticket to request SLA credit. Further information can be found here:

I read the linked content and a couple questions immediately popped into my head.

In order to receive any credit offered under this SLA, You must initiate a support ticket related to the event AND expressly request that We issue a credit. DO NOT ASSUME THAT WE ARE AWARE OF YOUR OUTAGE. Your outage may be wholly unrelated to Vultr’s services, so unless You contact Us via a support ticket, We may not be aware any problem exists.

Why are they yelling at the customer? How can they possibly “not be aware that any problem exists” when their marketing page says “our engineering team utilizes active monitoring to proactively detect problems and take preventative measures, minimizing any impact failing host node hardware could have on your environment.”

If Vultr needs to perform scheduled maintenance on your node, this is exempt, unless of course it takes us more than 10 minutes!

In what universe is 100% – 10 minutes (or any number for that matter) = 100%?

In accordance with the procedure outlined below, you must initiate a support ticket and request that a credit be applied to your account. Merely initiating a support ticket related to an outage will not result in any credit to your account.


The most important questions that I had were why couldn’t the support team send me that link and why isn’t there an asterisk next to the 100% SLA on the marketing site?

To be honest, I could care less about the actual reimbursement. The server itself costs a trivial amount of money per month, and the downtime was not that disruptive to me. The thing that really makes me frustrated is this deceptive and seemingly marketing driven SLA copy. Its makes me feel that I cannot in good conscience recommend this service to anyone else. If you are going to make such a grand claim as a 100% SLA you should either live up to it (which includes not making the customer jump through hoops in order to use it) or not make these types of promises at all.