meil.no mail disruption 27 August

On 27 August 2026, the host that runs the meil mail platform exhausted its available disk capacity. From 11:52 CEST the mail store could no longer append data to disk, and any request that needed to write returned an error.

Because the interfaces share the same storage, all of them failed at the same moment:

• webmail and the JMAP interface used by the meil apps
• IMAP and IMAPS
• SMTP reception and authenticated submission

The capacity was consumed by operational data on the host - build and release artifacts kept after deployment, and log data that had not been aged out. It was not consumed by customer mailbox data. Those artifacts occupied space that should have remained available for safe mail-service operation.

Our alerting failed completely. The storage condition raised no alert, and the disruption went undetected for a long time after customers were first affected. The length of this incident reflects how long the condition went unnoticed, not the difficulty of the repair: the mail service resumed normal operation within seconds of capacity being restored. We regard this as a serious failure on our part, and corrective measures have been put in place.

The same condition also disabled the service's own logging. From 12:52 CEST the mail service could not write its log file, so detailed telemetry for the remainder of the incident does not exist. A host under storage pressure loses precisely the signals needed to diagnose it, and that is part of what we are correcting.

Free capacity was restored at 18:35 CEST, and the mail service resumed normal operation and logging at 18:36 CEST.

Times in this report are CEST (UTC+2). The timeline below is rendered in UTC.

Between 11:52 and 18:36 CEST:

• Webmail could show an empty mailbox, or fail to load folders and messages.
• JMAP and IMAP/IMAPS clients could fail to synchronise, or return temporary mailbox errors.
• Incoming and outgoing SMTP and submission traffic could be delayed or receive a temporary delivery failure while messages could not be reliably stored or queued.
• Signing in was not affected, because account sign-in is served by a separate system, but the mail experience could appear incomplete after sign-in.

Mail systems normally retry temporary delivery failures. Messages sent to or from meil accounts during the incident may therefore have arrived after a delay rather than having been lost. A sending system that exhausted its own retry period before 18:36 CEST would have returned a non-delivery notice to its sender.

What was not affected

We have no evidence of unauthorised access to customer data, and no evidence of loss of stored mailbox data. The failure prevented new writes; it did not delete or alter what was already stored. Account sign-in is handled by a separate system and remained available, and no customer mailbox data and no backups were deleted as part of the remediation.

Any material update to the impact described here will be published on this page.

• Free capacity was restored on the affected host. No customer mailbox data and no backups were deleted as part of the remediation.
• The mail service resumed writing to storage, and resumed its own logging, at 18:36 CEST.
• Mail service health, mailbox access and new message processing were verified after restoration.

All corrective measures are in place.

• Alerting. The alerting that should have caught this condition failed completely, and the disruption went undetected for far too long. This is the failure we regard most seriously. It has been corrected.
• Retention for operational data. Retention is enforced for temporary release artifacts and operational logs on the mail host, so that operational data cannot grow into the capacity the mail service depends on.
• Per-interface customer-facing checks. Webmail/JMAP, IMAP/IMAPS, SMTP reception, authenticated submission and queue processing are monitored as separate customer-facing checks, so that a shared storage failure is visible on each interface.
• Alerting on loss of telemetry. A mail service that stops writing its own log is now treated as a failure signal in its own right. During this incident it was not.
• Post-incident review. Delayed delivery and queue recovery have been reviewed.

If a message sent during the incident window has not arrived after the sender's normal retry period, please contact support with the approximate send time and sender domain.