Some systems are experiencing issues

Past Incidents

26th September 2024

No incidents reported

25th September 2024

No incidents reported

24th September 2024

No incidents reported

23rd September 2024

No incidents reported

22nd September 2024

No incidents reported

21st September 2024

Email: Germany DE forwarding main server blocked by Microsoft

One of our DE MX servers, mx2.de.opalstack.com on IP 178.162.221.165, was recently blocked by Microsoft. As a result, mail sent to addresses which forward to Microsoft services like hotmail.com, outlook.com, and their international variants would be bounced back to the original sender with an error message.

We've already resolved this issue with Microsoft but they say that it may take 24-48 hours for the block to be fully lifted.

We'll update this post after we've seen no further blocks in a 24 hour period.

  • We've seen no further issues since our previous update.

    • 20th September 2024

    No incidents reported

    19th September 2024

    Web: Phoenix MariaDB down on opal7

    The MariaDB service on opal7.opalstack.com (Phoenix AZ shared hosting) is currently down. We're attempting to restore service and will follow up as soon as possible.

  • The recovery and repair is complete and the MariaDB service is operating normally.

  • The cause of the MariaDB outage was corruption in the service's InnoDB store.

    The service is now operational while running recovery and repair routines in the background. We expect the recovery and repair to take several hours but the service should remain operational in the interim.

  • The MariaDB service is back online at this time but service may be intermittent as we continue to troubleshoot.

    • Web: Frankfurt opal6 under heavy load

    opal6.opalstack.com (Fraankfurt shared hosting) is currently under heavy load and is responding very slowly. We're attempting to identify and correct the cause at this time and will follow up when more info is available.

  • The server is back online following the reboot. The cause was a runaway Apache httpd process consuming all of the server's available RAM.

    We'll identify the site that caused the problem and will work with the site owner to prevent the problem from occurring again.

  • We're unable to troubleshoot due to the extremely high load, so we are rebooting the server at this time.