I’m trying to get a better understanding of Capacity as well as being able to understand what the reports are telling me.
I recently received this email from Bubble.
“We are sending this email to let you know that your application X has hit its maximum capacity usage for 11 minutes over the last 24 hours.”
From reading through Bubble Forum I understand that capacity is the size of the pipe, and more capacity won’t make things go through the pipe faster unless there is more data at one time trying to get through a smaller pipe, and that’s when your system will slow down.
With that said, looking at the reports I’m not sure what I’m looking for. None of these look like I’m hitting capacity often. The top left chart looks flatlined at 0%.
Workflow runs it looks like I had a spike of 470, but is that a lot? Same time the capacity was still 0%.
Page views seem all over the place, but again max 35 page views does not feel like a lot.
Where and at what point should I be concerned? Is my breakdown between Backend tasks and Web requests good, or does this mean my app could be improved?
These are great questions! You are correct that the top left chart in your screenshot is flat, and I can also see that the timeframe in question is reporting 0 minutes of time when the app hit its capacity at the selected window.
If you enter a window of time in the inputs that contains the time that you received the email, you should see a small bump in that top left chart, similar to what you see in the top right chart.
When that bump is present, its worth investigating to make sure that you don’t have any problematic workflows. The best approach is as follows:
“Zoom in” on the general timeframe of the bump by decreasing the start and end times of the inputs to more generally fit the times reflected by the start and end of the hump.
You’ll notice as you do this, the hump will appear bigger. That is because the chart is looking at a percentage of a designated time period that a particular issue is impacting, so by nature, the smaller the time period, the higher the percentage.
Continue doing this until you zoom in on a time period where you notice the capacity is spiking to 100%.
Navigate to the “server logs” sub tab and enter this exact same timeframe.
You should then receive a list of logs that reflect the workflows being run at the time that the app was hitting capacity. This should give you a really good idea of what is causing the capacity spike.
Thank you. I did the first part(see attached image), but I guess I waited to long. It says my plan only has 24 hour logs. I’ll have to wait until I get another email.
If it was only that once on 7/28/2022 then it does not sound like I’m hitting that cap very often.
Since the capacity spike in this case seems to line up with the workflow runs and page views, I would say this is most likely a legitimate increase in traffic during that time period that led to the capacity spike!
Am I understanding the page views was only 3 page views and 5 Workflow runs? That seems like if I get more people on the platform it will crash. I would think it could handle 100’s if not 1000’s of page views without hitting a cap.
Based on the numbers here, it seems like the workflow or workflows involved here may be fairly expensive (ie: something recursive, or something that processes a ton of data). It certainly isn’t “3 people being logged on at once” or “5 workflows being run concurrently” as general concepts that are causing this capacity spike. I’d say its probably worth reaching out to our support team by filling out a bug report - this way, we can dive in to your specific app and see if we can come up with an explanation here.
I received a similar email. Following your instructions, I drilled down and discovered there were no workflows run during this time. In fact the capacity limit was 100% “Web Request”.
What does this mean?
Web requests generally refer to page loads in your application.
This is generally a pretty good sign of either a legitimate spike in traffic or some sort of pen test or URL attack on your application. I hesitate to use the word “attack” here because this is really nothing to worry about at all - these types of “attempted attacks” are incredibly unsophisticated, and generally just try to test different URL parameters hoping that something they test gets them access to some sort of valuable data they shouldn’t have access to. As long as you have all data protected via privacy rules, and you aren’t using URL parameters to trigger any sort of download operations or anything other than typical element visibility you are in good shape. These types of things are common for any application.
Its worth reaching out to our bug investigation team via the bug report form so that we can take a look and confirm exactly what is happening here, but ultimately - if this is a pen test these types of things are common and you shouldn’t be worried at all.
OK @sam.morgan Since there are no users (in development), it must have been some sort of attack. I have replied to the email, and got a response that Bubble is looking into it. Should I still fill out a bug report?
Nope, it sounds like you are all set! If you replied to that email and we responded, then that means the email was escalated to the proper team for investigation.
Again I just want to reiterate here because I know the concept of an “attack” on your app can be quite concerning - this is completely normal and nothing to be concerned about. These attacks are unsophisticated, and we have the measures in place to ensure they can not possibly access anything in your app they are not supposed to have access to already. The only real inconvenience caused by them are these temporary spikes in capacity, which, if problematic for you (ie: it is causing slowness for other active users of your application) we can take measures on the backend to ensure your capacity is opened up.
We get those emails all the time on new sites we have in development. The timeframe mentioned in the emails are, generally, off by an order of magnitude (from what I’ve seen). So if the email says your app was at capacity for 11 minutes, it probably was only for 11 seconds. I usually ignore these emails, however they are good for pointing out when I’ve created an out-of-control iterative scheduled API.
The graphs and metrics on the the app editor seem to correspond more closely to reality.
I reached out to bubble support. A lot of my clients had the same issue and it was related to a bubble server going down. Nothing you app did led to this spike! Just thought I would let you know and anyone else who may of had this issue as well.
