I can’t make any payments. The debit order failed and now I’m trying to update card details but even though it takes the new card details, it doesn’t take the payment. When I use GPay it says that the amount due is $0. All my projects stopped working. Even the Unboosted ones.
I tried to unsubscribe and resubscribe but it doesn’t allow me to unsubscribe either.
I received this payload that suggests that there’s an issue with the Glitch endpoint and I’m not sure if it’s relevant to my subscription or not:
Received request for WhatsApp webhook: {
“entry”: [
{
“id”: “3986900999218”,
“time”: 1733883845,
“changes”: [
{
“value”: {
“event”: “ENDPOINT_AVAILABILITY”,
“message”: “Flow endpoint availability has breached the 90% threshold in the last 10 minutes. Users will be unable to open or use the flow.”,
“flow_id”: “401334023624”,
“availability”: 50,
“threshold”: 90,
“alert_state”: “ACTIVATED”
},
“field”: “flows”
}
]
}
],
“object”: “whatsapp_business_account”
}
My Glitch endpoint for a WhatsApp chatbot keeps losing it’s availability. I’m getting this in the logs:
Received request for WhatsApp webhook: {
“entry”: [
{
“id”: “3986999218”,
“time”: 1733883845,
“changes”: [
{
“value”: {
“event”: “ENDPOINT_AVAILABILITY”,
“message”: “Flow endpoint availability has breached the 90% threshold in the last 10 minutes. Users will be unable to open or use the flow.”,
“flow_id”: “401333624”,
“availability”: 50,
“threshold”: 90,
“alert_state”: “ACTIVATED”
},
“field”: “flows”
}
]
}
],
“object”: “whatsapp_business_account”
}
Could this be related to the issues that I’m having with my Pro subscription payment? I have tried to contact support about it but got no response.
The payload you’re showing says “Flow endpoint availability has breached the 90% threshold in the last 10 minutes. Users will be unable to open or use the flow.” so I assume you’re getting rate limited by WhatsApp, rather than this being related to Glitch.
Hi @Pieter_le_Roux, I’m so sorry for the frustration you’re experiencing! Could you send this info to support@glitch.com so someone on our team can take a look? Thank you!
Thank you for the response. Facebook sent me this message for all my Glitch chatbots though:
Your Webhooks subscription callback URL has not been accepting updates.
Your Webhooks subscription for callback URL https://vast-tropical-terrier.glitch.me/ has not been accepting updates for at least 1 day. Please verify that your callback server is functioning. Visit our reference documentation to learn how to update your callback URL.
If your callback URL is still failing after 3 days your subscription will be disabled. To reactivate, just make a POST request with the same parameters or visit the Webhooks tab in the app dashboard.
You can view this and other Developer Notifications related to your app, in the App Dashboard.
I see a “bad request” on your domain so presumably it doesn’t have a landing page, but the standard questions apply: have you confirmed that your server’s configured to accept the requests being made to it? (e.g. have you tried manually curling it with a webhook payload to see what it does?)
If the server itself works fine when you curl it with the exact same data that WhatsApp sends, but messages from your phone don’t, and you’re following their API documentation, then that really does sound like you need to contact WhatsApp for, to see if you can more information about what’s actually going wrong. There’s not much you can do on the Glitch side if your project’s working fine for manual tests.
I have 3 WhatsApp chatbots running in Glitch and all 3 of them suddenly goes unresponsive every time they get some traffic with this in the logs:
Endpoint availability warning: Flow endpoint availability has breached the 90% threshold in the last 10 minutes. Users will be unable to open or use the flow.
But the Meta app dashboard shows that 0% of Application Rate Limit is being used. Can anyone suggest possible causes or would someone like to have a look at the code maybe? https://vast-tropical-terrier.glitch.me
do they not give you diagnostics about what goes wrong with the request? if not, then you probably have to try making a request yourself to see if it works.
and see if they have any timeouts, they might be giving up while glitch wakes up the project and installs dependencies
see if you can find any difference between your request and the request that whatsapp sends. certain headers can change how glitch processes a request, e.g. the user-agent header
I have WhatsApp chatbots that get long delays for responding to incoming messages at times and then works perfectly again after somewhere between 1 - 5 hours. When they become unresponsive then they return this error in the logs:
“Flow endpoint availability has breached the 90% threshold in the last 10 minutes. Users will be unable to open or use the flow.”
I opened this specific WhatsApp flow from this warning, and it’s insights and metrics shows that it has not been opened, or used, or delivered, at all, today, or during the last 7 days.
My Meta Apps have 0 users that are being rate limited and they are set to live mode if that’s relevant.
Hi Pomax, the issue hasn’t been resolved and support doesn’t respond to emails. Is there anything I can do to get assistance? I have a Glitch Pro account so I think it’s reasonable to ask for assistance?
That it is, but the error you’ve shown in your posts so far all point to errors that come from the third party service, Glitch does not have anything called “flow”, that’s a WhatsApp-specific concept and the errors you’ve shown are all about having run out of whatever amount of API functionality you’ve paid WhatsApp for. That’s not something that can be fixed by us.
As far as I can tell, the error is telling you that either the plan you’re paying for on the WhatsApp side does not include as many webhook calls as you’re using, and so you’re hitting the limit of your WhatsApp plan, or you’re calling the endpoint at such a rate that you’re getting rate limited. (based on reading through Webhooks - WhatsApp Flows - Documentation - Meta for Developers)
Did you already contact WhatsApp? What did they say?
Thank you for your response. The below endpoint is a demo and we use it about once a week. It can’t possibly run into any limitations. Yesterday someone tried to use it, he was the only person using it, and it was unresponsive for about 5 hours. Today it responded immediately, but it kept responding to messages at about an hourly rate even though I am not sending it any messages. I’ve received 8 responses from it so far today for no reason. It doesn’t seem like a WhatsApp issue if it’s sending me random messages at times and goes unresponsive at times. This is the specific endpoint for the demo: https://glitch.com/edit/#!/steers-chatbot?path=server.js%3A1%3A0
Hi @Pieter_le_Roux just a headsup that I’ve combined the four topics you had opened on this here in the forum into this one, if you could keep discussions on this issue to a single thread that would be great, thanks!
As frustrating as it might be, the errors that I’m seeing in your project log really do just come from the WhatsApp side: your web hook route is getting called with payloads that are about the state of the endpoint on the WhatsApp side, either that the end point can service your API use or that became available again, so at this point there’s nothing I can see that’s obviously Glitch related and I can only offer two ways forward in terms of figuring this one out (as project-specific code review is out of scope for Glitch support):
Contact WhatsApp and ask them if they can see anything weird happening with your calls (call type, call volume, call payloads, etc.) and
Remix your project and then reduce that copy to a “toy” mini project that has just enough code to reproduce the problem, so you can ask for help with making that work over on https://stackoverflow.com
Although step 2 is, in general, a good thing to try: often while you’re reducing your code you end up looking at things more critically, and you end up with so little code that it becomes much easier to compare it to what docs suggest should happen, leading you to find (or even outright solve) the underlying problem.
You may also want to see what happens if you temporarily host this code somewhere else (e.g. a digital ocean droplet or the like) to see if the problem occurs there, too. That’s a fairly drastic measure but would give you much stronger evidence about what’s going wrong.