All systems are operational
Maintenance
Scheduled DE IMAP/POP3 email server downtime

On 24 September 2026 at between 07:00 am and 10:00 am UTC our network team will be relocating one of our mailbox storage servers to a new location within the data center.

The server will be offline during the relocation. As a result, some customer mailboxes will be unavailable for up to 3 hours during the relocation. Affected customers will be notified directly via email.

Affected customers will not be able to check their email for affected mailboxes during the relocation.

No incoming mail will be lost during the relocation. Mail that arrives during the relocation will be deferred and delivered once connectivity to the mail server is restored.

Email forwarding and SMTP services will not be affected, however messages sent via SMTP during the relocation will not be stored as sent mail in IMAP folders on the server.

Customer websites will not be affected by the relocation.

We realize that the timing of this relocation may not be ideal. Customer who would like to have their mailboxes migrated to a different server in advance of the server relocation should contact the Opalstack support team to make the necessary arrangements.

We'll update our status page at http://status.opalstack.com/ at the beginning of the maintenance window. To be informed of system status updates automatically please subscribe at https://status.opalstack.com/subscribe.

If you have any questions or concerns regarding this maintenance then please email our support team and someone from our team will get back to you as soon as possible.

Past Incidents

29th April 2020

No incidents reported

28th April 2020

No incidents reported

27th April 2020

No incidents reported

26th April 2020

No incidents reported

25th April 2020

No incidents reported

24th April 2020

Web: Dallas Apache was not responding on Opal4

The Apache service on Opal4 was not responding for approximately 1 hour today beginning 18:23 UTC.

The problem was that the Apache service had hit its configured ServerLimit which meant that no further Apache processes could spawn to handle requests. That has been corrected and the service is online now.

We're now investigating the root cause and also looking into why our own monitoring systems did not alert us to this condition.

  • The root cause appears to have been a misconfigured customer application. We've corrected the configuration and have updated our monitoring system to alert us when Apache approaches its configured limits.

  • 23rd April 2020

    No incidents reported