I am composing a mail to Siteground about the outages on my primary production website.
You reported over 100 DOWN Alerts between Between 23rd Jan and 19th June this year on my primary domain https://guesthouse.live. These were corroborated by alerts from Automatic (via Jetpack).
They ranged between 2 an 21 minute – I haven't done the maths I would guess the average would around 4 minutes.
In fact 61 on the 100 alerts are for exactly 4min which might suggest that this is your polling interval except sometimes is 2 or 3 minutes.
Can you please tell me:
1) What is the polling interval that you check the server availability.
2) Does this interval change when a site is down? For minutes? Hour? days?
ie.e You normally might poll once every 4 minutes, if the site DOWN you increase to 1 minute for say 1 DAY then assume the site deliberately down and throttle back.
I ask because the dow time that you report are very often 4 and 8 minutes minutes but can be 2, 3, 4, 5 ,6 17 21 etc. So
3) What exactly is initiated the check: GET HTTPS?
40 You also measure measure RESPONSE Time. Time to first byte received?
When I request the hub to produce an uptime report for the lats 30 days.
YOUR WEBSITE IS UP
Available for 1d 21h 47m
AVERAGE RESPONSE TIME 2,262ms: Calculated from Virginia, USA
UP SINCE JUL 14, 2019 12:01PM
EMAIL NOTIFICATIONS: ON
You note two downtimes
Jul 2, 2019 1:52pm: downtime502 Bad Gateway
Jul 2, 2019 2:10pm: uptime
REASON: 502 Bad Gateway
This one btw I have traced to an Cloudflare outages:
"Starting at 1342 UTC today we experienced a global outage across our network that resulted in visitors to Cloudflare-proxied domains being shown 502 errors (“Bad Gateway”). "
Jun 19, 2019 1:56am: downtime
Jun 19, 2019 1:58am: uptime
REASON: 500 Internal Server Error
If my site was down 1d 21h 47m ago why is there no outage report.
The only thing I can think of is that uptime monitoring was switched off for some reason seem time between Jul 2 and Jul 14 so uptime was not being recored during this time. Is this correct.
Also notice a discrepancy between the downtime reported in my email alert and the downtimes reported on the panel.
Panel: Jul 2, 2019 1:52pm – Jul 2, 2019 2:10pm 17mins (BAD GATEWAY)
Email: Jul 2, 2019 1:48pm – Jul 2, 2019 2:10pm 21mins (BAD GATEWAY)
Panel: Jun 19, 2019 1:56am: – Jul 2, 2019 1:58am: 2 minutes (Internal Server Error)
Email: Jul 2, 2019 1:46pm – Jul 2, 2019 2:10pm 21mins (Internal Server Error)
Its a small thing but want to get my fact right.
I pretty that sure the majority of the other outages were caused by certain IMAP email clients leaving persistent IMAP Push processes on the server (these are the one that some client use so you don't have to refresh to receive new email).
I don't know whether you've ever come across this issue but it could effect anyone who is using a shared service with email and web-hosting.
It's not so much that the processes are consuming huge CPU resources , it that the number process can build pretty quickly. And in may case for instance I have limit of 20 processes.
For example on IMAP Email clients:
1 process is created PER EMAIL ACCOUNT each time a user initiate a sync. Press the sync button 2 or 3 time in frustration and you'll get 2 or 3 processes per account.
These are temporary and will disappear once the account has synchronised.
At the same time and concurrently the email app create another 1 process PER EMAIL ACCOUNT that it leaves behind and will persist as long as the email client is running.
Worst of all though there are some email client that at time and concurrently create another 1 process per PER EMAIL ACCOUNT for the purposes of synchronisation with a cloud baed synchronisation service.
So if like me you have 8 email accounts on your client you could have an initial burst of up to 24 or more processes – exceeding my 20 process limit.
However 16 remain until you close down the email client.
Then 8 remain iFOREVER. That right they cannot be killed. They just respawn. I cannot block the IP's they just come up on another Google Cloud IP.
In FACT they NEVER go away. I still have the processes spawned on Jul 11 today on Jul 17.
I believe this is an issue that could effect any user of shared hosting service which include provisions of IMAP email boxes.
I can tell you today that I have carried extensive testing of the following Mac Email Clients:
These clients either have email push turned off be default and it cannot be switched on (like Mac Mail) of they have configuration of options
Apple Mac Mail Version 1 2.4 (3445.104.11) apple.com
Mozilla Thunderbird 68.0b3 (64-bit) mozilla.org
Microsoft Outlook for Mac Version 16.26 microsoft.com
Eudora 220.127.116.11b (yes someones still maintaining it)
Postbox. 6.1.18 email@example.com.
Postbox is the only one of the new breed of Appstore email clients that has the configuration to disable IMPA Push.
I would strongly recommend that your member do not use these other client with a shared service.
MailMate Version 1.12.5 (5635) firstname.lastname@example.org
Newton 10.0.18 email@example.com
Unibox Version 1.9.2 (444) firstname.lastname@example.org
Airmail Version 3.6.60 (549) email@example.com
Seamonkey 2.49.4 firstname.lastname@example.org
Canary Mail 275 email@example.com
The worst offender are these two which also create the extra Google cloud sync processes.
Of the two Spark is the real criminal because it creates these persistent processes for every account configured in the client, whereas with Mailspring you can choose just to sync one account at a time.
Mailspring Version 1.6.3 (1.6.3) firstname.lastname@example.org
Spark v636 (7751fef) email@example.com
I have emailed all these companies explaining the issue but there response has been underwhelming to say the least.
I guess if you're not on a tightly budgeted hosting service and your used to iCloud or gmail you don't think twice about these things.
The other issue is server storage space that these IMAP email accounts can use up. On I iCloud have got 160,000 email over 10 years taking up 16GB !!!!
Again there are NO server config (On any of the three Siteground webmail apps anyway) that will automatically maintain your server IMAP mailboxes below they quota.
To give you an idea I have webmaster email account which receive a daily log from a backup plugin which is about 7MB in size. If the quota for that account is set to 250MB it fills up in 35 days.
I've have several account per site for contactus, privacy etc. Most are low use so I can set the mailbox quota low. But the maths is simple 6 sites x 6 email per site = 36 account. High Volume: 2 x 6 per site x 250MB. = 3GB. Low Volume: 4 x 6 x 50MB = 1.2 GB. Thats 4+ GB out of total of 20 GB.
So you can't keep extending the quota forever. Once the quota is exceeded email will start bouncing back – potentially to the end user depending on your WordPress setup.
The only way to automate the management of these account to auto archive unread mails from IMAP Server Mailboxes is to have Email Client which have rules which can regularly archive mails out the IMAP mailboxes an into a locally stored archive.
Again Ive found the new crop fo email client do not have the rule processing functionality to achieving: only the old classics: Mac Mail, Outlook, Thunderbird etc are up to the job.
Its a shame because some of these new mail client have fantastic UI's and amazing integrations. I can forward email to iTunes if I wan to.
But unless they can do the boring stuff managing their server load and storage space I have to warn people against using them for a set up like mine.
I will be publishing a comparative review of Mac mail clients – for which I had the WordPress Developers/Support Freelancer with multiple client sites in mind.
On my local Mac development environment I now have different client sites in different workspaces which helps keeps things separate.
Having separate email client was the last piece of the jigsaw puzzle but it looks like I'm gonna have fine some other way to segment site emails.
If you think your WPMU member would be interested in a copy of my article I will happily syndicate it to you for free.