I see everything is working now. Sorry for the inconvenience. I asked the responsible team to share why this happened again.
The health check API is still not shared. Without that, we are strictly thinking of replacing aspose as it is very embarrassing for us to know that a aspose is down from our clients. This is getting repeated, and our business has been impacted a lot.
2 Likes
We have been on a paid Aspose package, and in this month alone, we have experienced multiple outagesâsometimes even multiple in a single day. Each time we report the issue, we receive a response stating that the problem has been resolved and is being monitored. However, the outages continue to occur.
Previously, we were told that the outages were due to a Billing API migration aimed at ensuring 100% uptime. Yet, even after the migration was âfully completedâ and âfine-tuning fixesâ were applied, we are still facing the same issue.
This recurring problem has directly impacted our business, leading to financial and operational losses. Despite raising this concern multiple times through the public forum and paid support, we are yet to receive a clear and permanent resolution.
We need:
- A detailed root cause analysis explaining why these outages keep happening.
- A clear action plan to ensure service reliability moving forward.
- Compensation or SLA credits for the repeated downtime.
This is no longer just an inconvenienceâit is affecting our ability to serve our customers. Please escalate this matter immediately and provide a concrete solution rather than just temporary fixes.
Looking forward to a prompt and serious response.
2 Likes
The investigation is ongoing; they restored the serviceâs work but are analyzing logs for more information. Once they finished their analysis they will update this topic with full RCA.
Speaking of your 3 point please contact sales team.
Here is a complete statement from the billing team.
The investigation was concluded, and we determined that a very large number of failed API calls to the /connect/token endpoint was likely the cause of the issue. To mitigate this, we implemented a rate limiter: if a user makes more than 20 failed POST requests to /connect/token within a minute, they will be temporarily blocked from accessing the endpoint for a cooldown period of 10 minutes. When a request is rejected, the system responds with a 429 Too Many Requests status and includes a Retry-After header.
hi team. I wanted to check the progress on the response status check URL to verify if something was wrong. I am referring to this link where we see info : https://status.aspose.cloud/
After the analysis, we concluded that such an endpoint is out of the scope of our product, I mean Aspose Words Cloud, as we canât get all that information. You should check our /info endpoint for all the information we have. I mean, if billing responded to us, then it means that we sent information about the license and consumption. Suppose you observe the behavior when the license information is okay but containers are in evaluation mode. In that case, it means there is a bug, so please share information about it, and I will proceed to the billing team so they will figure it out.
Actually the thing is, we are expecting an api endpoint where we can know the status of aspose so as to make a call to aspose apis or not. We should not hit info API before every call, right? Even in the past we have noticed its response structure be coming as inconsistent.
No, you donât need to call /info API before every call. You should update the image to the 25.3 version where updated billing is used, and the grace period is 7 days, so it would be enough, in general, to call /info API once every couple of days to ensure that all your usage is sent to the service.
If you encounter that the info response doesnât contain all the necessary fields, please feel free to contact us. However, please upgrade the image version before, as it is crucial to have a 7-day grace period.
1 Like