Since glide doesn’t have a good backup option for our apps, I duplicated the app we are using to manage our whole company. The problem is that when I tried to move it to a backup team to store it, glide didn’t allowed me because on my backup team I don’t have a payment option (Obviously!). The problem is that, since it is a backup, it uses the same sheet as database. Also, I was starting creating another app based on the same sheet (STARTING! DIDN’T SPENT EVEN 30 MINUTES WORKING ON IT YET) it started charging me too, even with no users on this new app accessing it. How can I start escalating my business using glide if I can’t have a backup and the security that I will be charged a lot more than my budget allows at any time?
Before someone says that I can turn off the “Prevent interruptions allowing overages when you reach your plan limits at $10 per 1,000 updates.”, my company can’t stop at any time because of it. But being charged this much for apps I don’t have any logged in user is very frustrating.
Does anyone is having problems like that? How do you guys seeing yourselves using glide after scallating your companies?
I believe your backup team should only need payment information. You don’t necessarily need to be subscribed to a plan.
Also, you are showing row counts for each app. That shouldn’t be the problem. What is your update count for the team? Updates is where the ‘Pay as you Go’ feature kicks in.
I guess my first question would be if you are using any integrations. Integrations can use server processing time, so I think updates may still be counted if those integrations are called, whereas basic data editing does not count when in the builder. Is it possible that you have a bunch of columns with integrations that needed to recalculate after you duplicated the app?
It looks like you were charged this due to high updates usage–the updates you are using (mostly Edits) are only counted for published apps, and have nothing to do with the number of rows used or how many apps you had.
In your case, the Strike Manager app looks like it’s pushing lots of edits. You can see this on your Usage (beta) screen.
In any case, if there was an error, we can refund or credit you, but from what I can see, you are being charged correctly.
I sent the wrong printscreen, sorry. I was taking a closer look at it and I may have found what happened, but it is still a bug from glide and that worries me a lot. Take a look at the usage (beta):
they separate the call api from the basic data editing, I it is only using 3981 calls. My updates count wasn’t even close to this much before integrations. Here is what worries me. It is kind of hard to explain, but I will try:
I have one call that do the following thing:
I have to update the financial status of my clients daily and it is separated on two options (ADIMPLENTE (paid) or INADIMPLENTE (unpaid).
I have two apps that use the same database. The STRIKE MANAGER is the company admin, and the Strike Platform is an app for my clients.
At the STRIKE MANAGER I have 9 call api columns that call daily, but it is just two rows, so the number of updates would be: 9 columns x 2 rows x 30 days = 540 calls. In this call apis I bring the information of not paid invoices, so I can relate to the clients sheet to undestand if their status are PAID or UNPAID.
Since the Strike Platform is a classic app and doesn’t allow me to use call api, I created one call api column that mutates a basic column on the clients sheet, but only if the client status is not paid. So, in this case if the client status is not (UNPAID) it is PAID.
I use one of these API column call daily, so it would be 1 column x 1 row x 30 days = 30 calls.
I do this by grouping the mutations on a joined list and then using it at as the body for the call API, so I would use just one call api to update this rows.
Since most clients have PAID status, it would only change the value when a status client PAID (adimplente in portuguese) become UNPAID (inadimplente in portuguese), and since updates just count when the value changes, it would charge for all 992 rows. I am already being charged for the call api from glide to glide and even considering that glides charge for the updates from the call api glide to glide, in the worst case scenario, having 200 UNPAID clients, the updates should be around (200 rows x 30 days = 6000 updates)
The exceeding usage that I was expecting after implementing (considering this 6000 updates from glide to glide) was the maximum of 540 + 30 + 6000 = 6570 updates.
The problem is that if exceeded on around 40,000 updates from my usual usage. You can take a look on the last months,
What I believe that is happening is that each update on the basic column, even when the value isn’t changing is counting as an update, even if the value isnt’t changing. And I believe it is happening because It was coming from a call api.
I can just check this theory with the logs, but it is the only thing that makes sense to me. The usage increased from month to month on more than 160%, and I didn’t implemented this much new stuff on the app.
Also, It just charged the $649 dollars on my credit card (the renewal was today, November 20th) and it is already showing $74,500 updates and the message of update limit for my users (after I changed to fixed).
Sorry if I sounded rude or something like that on the last posts. I am just really worried because I definetivelly wasn’t expecting this kind of change and $649 is a lot in Brazil.
Every mutation counts as an update, regardless of whether or not values are being changed.
It sounds like you are sending way more mutations that you need to.
What you should do is implement logic such that mutations are only created and sent for those rows where the values need to be changed.
what I think that happened is that I had a computed column values that I needed to send to a basic column, so I could use it on a classic app (that is the app my clients use for a while). The problem is that looks like every mutation count as an update, regardless it comes from inside glide or not. Could the problem be this? Because from one month to another the updates increased too much (more than 160%), and my company didn’t grow that much this fast ( I hope it did, actually hahah)
David, its november 22nd and the renewal dated november 20th. How can I be sure that it’s reseting properly monthly? Could it be the reason the updates are way too high?
When I oppened this chat the total updates were around 67000 and two days after it is around 77000. On the Strike Manager, that is the most consuming app I have only 25 private users. For every active user user (which is not 25) to consume 10000 updates, they
Just to give you an idea of how weird this whole situation is:
On the Strike Manager, that is the most consuming app I have only 25 private users.
Glide charged me $649 dollars on the business plan. Which means that they estimate that I used de 25000 updates + 40000 updates, on a total around 65.000 updates on this month.
The other two apps consumed only around 8,000 updates each, so around 16,000 updates. Leaving the Strike Manager app with around 49,000 updates.
to consume 49,000 updates, I would have to consume on every day of the month (with saturdays and sundays included) around 49,000/30days = 1,633 updates per day, and I have only the maximum of 10 real active users.
We are confident that the charge for 40k updates was correct, but will double-check everything. We have a record of every single update (Edit for example) timestamped to when it occurred.
Thank you David. What I am more worried about is on how I can optimize my app if it is really exceeding 40k updates.
Also, I would really appreciatte if you can look if last month it reseted too, because the usage was almost doubled, and I didn’t added new users.
I received on my email the logs, but I couldn’t identify what actions, user or rows the updates occured. Every id I looked in there wasn’t on my app. If you could double check that I would really appreciatte too.
You are using the API, and sending batch mutations, so I would not worry too much about your number of users–this is not the culprit. If anything is driving unexpected updates, it would be your API use.
We confirmed that you were actually undercharged according to the number of updates used in your last cycle, so yes, we need to figure out how you are performing so many edits.
trank you David! And sorry for being so annoying about this, but my business partner wanted to kill me after seing how the increasing of the glide costs hahah
Just one last thing: the usage was really resetted, but even after the reset, on the Next Payment Estimate is still $669.
Exactly! I just would like to know where all this updates come from, because the app is big and it could be coming from. I already turned off the api call that was doing the mutations. If Glide provided a report with the information of what actions or fields are triggering all this updates, it would be a lot easier to know where I should start from.
