|Uptime / Load||Mar 14||Mar 15||Mar 16||Mar 17||Mar 18||Mar 19||Mar 20|
|File Storage Platform||100%|
Node HTTP Status
|N1 - San Francisco (USA)||100%|
|N2 - London (England)||100%|
|N3 - New York (USA)||99.991%|
|N4 - Toronto (Canada)||100%|
|N5 - San Francisco (USA)||99.998%|
|N6 - Amsterdam (NL)||100%|
|N7 - Toronto (Canada)||99.998%|
|N8 - Frankfurt (Germany)||100%|
|N9 - New York (USA)||99.998%|
|N10 - Toronto (Canada)||99.998%|
|N11 - New York (USA)||99.998%|
|N12 - Toronto (Canada)||99.998%|
Node Usage (Click to view CPU/LOAD/DISK)
| No/minor issues (>99.9% uptime) Short outage (>99% uptime) |
Issues reported Major outage (<99%) High Load Average
The upgrade is now finished, total time down 1.4 minutes.
We are running an emergency database upgrade for our cloud and community for scaled performance going forward. There are no problems atm but we are noticing a performance limit that we need to upgrade.
We ran into a issue we found out about after the fact when we did a TLS certificate renew on all nodes. When the renew was made the certificate had invalid permissions when copied to the new folder by our script and as such when the mail system restarted it did not have access to the certificate. This made the mail systems reject all TLS requests with "454 TLS currently unavailable". This has been fixed and all servers now in the auto renew code have this permissions update added to the process.