Why expiry value shifts back for 2 hours after subscription cancellation? It's not refund it's just renewal cancellation.
Initially subscriptions' duration is enlarged in 2 hours to have time gap for prolongation. After cancellation this time gap is subtracted.
Related
I have an alarm setup in AWS cloudwatch which generates a data point every hour. When its value is greater than or equal to 1, it goes to ALARM state. Following are the settings
On 2nd Nov, it got into ALARM state and then back to OK state in 3 hours. I'm just trying to understand why it took 3 hours to get back to the OK state instead of 1 hour because the metric run every hour.
Here's are the logs which prove that metric transited from ALARM to OK state in 3 hours.
Following is the graph which shows the data point value every hour.
This is probably because alarms are evaluated on longer period then your 1 hour. The period is evaluation range. In your case, the evaluation range could be longer then your 1 hour, thus it takes longer for it to change.
There is also thread about this behavior with extra info on AWS forum:
. Unexplainable delay between Alarm data breach and Alarm state change
I have scheduled Fixed rate of 2 days for an event rule. Where can I find the next run time?
It counts from the date and time you created the CloudWatch event. If your rate expression is rate(1 day) and you created the event at 22:00:00 UTC, then it will run at that time the next day. A rate expression for 2 days will fire two days later at the same time. And similarly a rate expression at 5 minutes will fire every five minutes beginning at the time the CloudWatch event was created.
To verify this, you can create a Lambda function that uploads an object to an S3 bucket, create a CloudWatch event for it, making note of the time you created it, and observe that when the event fires, the modification date of the object is that many days/minutes/hours from the time you created the event.
I am implementing in-app subscriptions with Google Play and synchronize the status of those through polling to Google Play API. The subscriptions have a trial period of 3 days and I expect Google API to return paymentState=0(Pending) or 1(Received) after the trial period has expired. This does not always happen for customers that have a payment failure, as Google keeps returning paymentState=0(Free trial).
It seems Google is giving a grace period, although I don't have any grace period configured for this subscription type.
Do you know why this happens and how should I update the trial period status when the 3 days of trial have expired?
Thanks
Reported this several times to google, the issue is still present, from my experience for some orders the SUBSCRIPTION_GRACE is sent >20 hours after the current cycle ends, and if you send validation request before this notification paymentState will still have value 1 or 2 instead of 0.
I have configured my API gateway with API key that has usage plan attached to it so that caller with the given API key can only make 1000 requests/day.
When I configure it for 1000 requests per day, does it mean it can make 1000 requests in any given 24 hour window? or It can make 1000 requests from 12 am untill 11:59 pm UTC in a given day?
It is one day UTC, so 1000 requests from 12am until 11:59pm UTC
If I'm not wrong, current Amazon Advertising API limit can be calculated based upon these digits:
2,000 + 500 * [Average associate revenue driven per day over the past 30 days period]/24
Are there any ways to get an amount of remaining requests?
For example: 2605 has been made and 1300 can be done till the end of current hour for my account (or something like that).
Or should I just rely on 503 error message ("Account limit of 2000 requests per hour exceeded") ?