11–20 of 278 posts
It feels like that could be a good practice, or not, depending on the laws in question.
I wonder if they’re open in other EU regions? If you wanted to shut down a region, as a database provider, is it even possible to send snapshots to another region without user consent? It feels like that could be a good practice, or not, depending on the laws in question.
They might not have been able to do it automatically as the region name were hardcoded in the hostname.
> According to the support, the notification emails to the users were sent on Feb 23, Apr 6 and May 15th. However, we did not receive those at all. If true, this is concerning. One message getting lost in spam understandable. But three over 6 months would imply they're being blacklisted and/or their mail sender is simply broken. Do serious companies not have canaries or other checks in place to ensure their notificat…
For these kind of automated emails getting all emails consistently being delivered to everyone is really hard, almost impossible.
The problem here isn't really that emails weren't being delivered, it's that they seem to have tried only one method to contact people, didn't check how successful that was (e.g. by seeing how many customers were still on those regions), and seemingly never tried anything else (such as notifications on the dashboard, a temporary brown-out to alert people, etc.) – "we tried one way to contact you and that didn't work, so we just deleted your service sucks to be you lol kthxfuckitybye"
Incidentally at work we've been evaluating a new hosted observability provider, looks like we can rule out Influx as an option.
This kind of thing really does need a cooling off period. Assume that your users won't see your emails. How do you help them avoid data loss when you shut down a service like this? One option that I like is to take the service down (hence loudly breaking things that were depending on it) but keep backed up copies of the data for a while longer - ideally a month or more, but maybe just two weeks. That way users who di…
you start with reliability brownouts. first fail 0.1% requests, then after a week 1%, then after a month 5%.
Also you probably can't keep charging customers for that period since you offer a crippled service on purpose.
This kind of thing really does need a cooling off period. Assume that your users won't see your emails. How do you help them avoid data loss when you shut down a service like this? One option that I like is to take the service down (hence loudly breaking things that were depending on it) but keep backed up copies of the data for a while longer - ideally a month or more, but maybe just two weeks. That way users who di…
you start with reliability brownouts. first fail 0.1% requests, then after a week 1%, then after a month 5%.
Stopping service and immediately delete data is just callous.
It's almost like using bullshit hype-hype-hype databases, especially their cloud offerings, is a horrible idea.
Wow, the incredibly callous 3-word explanation of the issue by pointing to a docs link with no other context. Really gives off "it's your fault for not reading the wiki." Is this how InfluxDB treats their customers? Incidentally at work we've been evaluating a new hosted observability provider, looks like we can rule out Influx as an option.
I don't see any indication that the person who posted that is associated with InfluxDB. In fact, it doesn't seem like any staff member has posted in that forum in the past week. Up to you if you consider that better or worse.