When will my Google Apps Script email recipients per day limit increase? - email

I am a G Suite user using Google Apps Scripts to trigger emails. This link says that I can email 1500 recipients per day but that...
"newly created G Suite domains are subject to the consumer limit for the first billing cycle if they have six or more users, or several billing cycles if they have fewer users".
This means I can only send 100 emails per day, which I am nearing.
I want to know how many billing cycles I have to wait for until my send limit will increase. I am the only user of the G Suite domain and the vagueness in the above quote isn't helping me. If anyone knows the answer and/or can suggest a solution to increasing the send limit now or a clever solution to cope whilst the limit is at it's current level, that would be greatly appreciated. Thanks

Related

Sendgrid free plan limited to 100 emails per day or month?

I'm using Sendgrid's free plan and it clearly states on their website that the limit is 100 daily; not monthly, yet I get capped at 100 for the entire month.
I read elsewhere that I needed to go to Settings > Account Details > Your Products > Start Trial to Send More, but I can't seem to find the "Start trial" option under the "Your Products" tab, or anywhere else for that matter.
Am I blind?
The Free Email API plan is 100/day. If you believe you are being incorrectly capped at 100/month, I'd reach out to their support team so they can check your account for limit accuracy and check sending volumes to confirm or troubleshoot the issue.

How to fix the quota problem of email wotj G Suite account?

I have some a script with trigger set up to send emails daily with GSuite account (about 10 triggers to send about 15 email in total per day, average 6 recipients/email.
However, last few days, I got the alert:
Exception: Service invoked too many times for one day: email
when running the script by trigger or by manually.
I do not think I hit the quota of sending email daily of Google. This morning, when I check the quota remaining by function MailApp.getRemainingDailyQuota(), I only get 4 email remaining. I do not know what happened.
Is there anyone could please help me to solve this problem?
This is the alert I receive:
Your script, AutomaticSendingEmail, has recently failed to finish
successfully. A summary of the failure(s) is shown below. To configure
the triggers for this script, or change your setting for receiving
future failure notifications, click here.
Start Function Error Message Trigger End
6/13/20 3:59 PM send_overtimerequest_email Exception: Service invoked too many times for one day: email. time-based 6/13/20 3:59 PM
Sincerely,
Looking at the page for Apps Script quotas it does specify that the limitations per day is counting recipient (100 recipient/day), so in this case you have no much option. Make sure that you are using the correct account because the limitation for G Suite accounts are 1500 recipient/day. Also check out if this may be applying to you right now:
Note: Newly created G Suite domains are subject to the consumer limit for the first billing cycle if they have six or more users, or several billing cycles if they have fewer users. For more information, see the Help Center page on sending limits.
A workaround that I would suggest is to have a service account and use Domain Wide Delegation to impersonate and user then make use of the Gmal API

How are Google Apps Script mail quotas calculated?

The Current Quotas table on the Quotas for Google Services page shows a feature called "Email read/write (excluding send)," which is limited to 50,000 / day for G Suite Business customers.
I have several Google Apps Scripts that use MailApp to send emails, and today users of my scripts started getting the error: "Service invoked too many times for one day: email"
When I ran MailApp.getRemainingDailyQuota() it showed -1, confirming that the quota had been exceeded.
When I checked Google Vault to see how many messages my account had sent between yesterday and today, it showed about 3,294.
When I reached out to G Suite Support to ask about this, they directed me to the G Suite Admin Email sending limits page, which shows that G Suite accounts are limited to sending 2,000 messages per rolling 24-hour period.
3,294 is greater than 2,000, but both are well below 50,000, so I'm wondering what actually counts against the 50,000 quota.
What mail-related operation does "read/write" pertain to?
We also use gsuite and Google script to send lots of mails. And also have lots of questions about quotas. The results of my observation is that limits applied with some lag. I can send over limit mails (some amount), before limitation will apply. Amount is vary and bit unpredictable, but almost always if I do sime pause before sending over limit mails - I got quota errors :(
I can't comment, thats why updating answer. Just try to add few mails into bcc :) and check metrics

Why is my mails staying in “backlog” of Mandrill?

at previous hour we reached the number of maximum limit of sending emails per hour which is not surprising since we know our limit per hour to send. However, after an hour passed I assumed that the rest of the emails will be sent automatically. It did not work that way. Now I have over 800 per hour to send and I sent 0 in this hour, at the same time, I see that 139 emails are backlogged from previous hour. Could you please help me how can I send those?
For everyone with a new account (and not over the hourly threshold) and still getting this problem, Mandrill can sometimes wrongly think your account is sending suspicious activity.
To check if this is the case go to the mandrill dashboard and in the bottom left click support. There should be an alert informing you to complete an account review.
You'll want to reach out to Mandrill support so they can look at your specific account. There's not enough information here about the API calls you're making or your account to be able to say what's happening.
It should be something related to your api if you are using api to send. Otherwise mandrill sends them right away as soon as you reach to next hour!
If you have just signed up for madrill then it usually takes longer time to prove your genuinity.
I suggest you to send a email with your details to help#mandrill.com and they will resolve it Max. 3 working days!
I did the same and they reverted within 30 hours and my mails are a breeze now!

Facebook Graph - What is the limit to send private messages from page to users?

I am developing a chat robot that works with private messages on facebook. The person sends a private message to a page that I own, and then I will send an answer for each message.
Everything is working, but I need to be sure facebook won't complain about the amount of messages I will send. This application will receive a lot of interactions at the same time, but in some early tests one of my messages were received like that:
http://cl.ly/image/1C1n0Z2L0R05
I am now using Batch Requests to send all messages, on an interval of 15s.
Do someone know some way to test it with multiple users and multiple messages at the same time? How the process of identification of spam messages work on facebook? How many messages can I send at the same time and in what time range to prevent that kind of behaviour?
Thanks.
There is no set limit or guideline on volume.
But really volume should not be the issue. There's a huge number of factors that is taken into account to determine if a message is spam... too many to discuss here. But you can assume basics: the content of the messages, the volume per user in a given time period, the content variation per user, has this app been flagged as spammy before, by how many users, etc. I would say its reasonable to assume your test user is probably going to be triggered as spammy because you're likely using it far far more than the average user would.
So, in short: it depends entirely on what exactly you're doing every 15 seconds.
Tip (although I cannot verify it): if you are trying to batch send a message to a number of users at once, without them very recently contacting you, you're probably gonna be flagged as spammy.