Hacker News new | ask | show | jobs
by jamesk_au 3326 days ago
Possibly relevant (from the Firebase FAQ[1]):

Why was my Realtime Database reported bandwidth lower than average between September 2016 and March 2017?

For our bandwidth calculations, we normally include SSL encryption overhead (based on layer 5 of the OSI model). However, in September 2016, we introduced a bug that caused our bandwidth reporting to ignore encryption overhead. This might have resulted in artificially low reported bandwidth and bills on your account for a few months.

We released a fix for the bug in late March 2017, returning bandwidth reporting and billing to their normal levels.

Does not excuse the issue with support.

[1] https://firebase.google.com/support/faq/

4 comments

How is expended computational power (to encrypt) relevant for the bandwidth bill though? I understand it's an expense for them, but (1) 7500% is not a correction in measurements (they must have noticed that over 2 years if it actually costs that much) and (2) it's a completely new expense category (if your plans are bandwidth-based, you can't just force someone into a larger plan when bandwidth stayed the same, you should announce and explain the change in plans).
I'm guessing they had to update this FAQ after they started ignoring the OP (and other customers) messages. Also, something is wrong with the timeline with regards to the OP's blogpost where they say they've been using Firebase for a while.
Yeah OP says they've been using FB with similar costs for over two years, so I highly doubt they're complaining about something that was only a problem for the last 6 months.
The original post claims they had the service for over two years and everything was smooth.

Something does not add up here.

> we introduced a bug

I know it's not the case, but this wording makes it sound intentional. May as well say "We designed an internal problem"

Not really. "Introduced a bug" is fairly common (just do a Google search and see), and clearly does not suggest intention.