meil.no webmail incident 10-11 July

Between 08:58 CEST on 10 July and 10:16 CEST on 11 July 2026, customers were unable to use the meil.no webmail interface or synchronise calendars and contacts through CalDAV and CardDAV.

The affected interfaces could not load mailboxes, identities, contacts, privacy aliases or calendars. In some cases, this made it appear as though email or other content had disappeared.

No email or other customer data was lost. Stored data remained intact throughout the incident. The underlying email platform continued to receive and send email, and access through standard email clients using IMAP and SMTP remained operational.

This was an availability incident, not a security breach. Our investigation found no evidence of unauthorised access, disclosure or modification of customer data.

The incident followed a planned internal security-maintenance change. The change unintentionally caused traffic from several internal services to be represented by a shared internal network identity. An automated protection mechanism subsequently blocked that identity after repeated failed authentication attempts originating from a single client. Because legitimate webmail and synchronisation traffic shared the same identity, the block affected all users of those services.

The duration of the incident was significantly longer than acceptable.

The first related customer report was received at 13:46 CEST on 10 July. A second customer contacted us at 21:46 the same evening. Both reports were classified as P4 and did not trigger incident escalation.

At 09:16 CEST on 11 July, a further customer email contained clearer evidence of a serious service-level problem. The severity was escalated, and active technical troubleshooting with the customer began at 09:46.

A public incident notice was published at 09:53. The root cause was identified and the affected configuration was corrected at 10:16. The public status page was marked as resolved at 10:18.

Once active technical troubleshooting began, service was restored within approximately 30 minutes. The preceding delay in detection and escalation was nevertheless unacceptable and represents a failure in both monitoring coverage and support triage.

We are improving authenticated service monitoring, support-classification procedures, automated prioritisation and the correlation of incoming reports with operational telemetry and recent production changes.

Our existing monitoring continued to report the core email platform as healthy because email receipt, submission, storage and standard IMAP and SMTP access remained operational.

We did not have a sufficiently complete authenticated end-to-end check that verified whether a user could:

• sign in to webmail
• load an actual mailbox
• retrieve identities and privacy aliases
• load calendars and contacts
• complete CalDAV and CardDAV synchronisation

First customer report

The first related customer report was received at 13:46 CEST on 10 July, approximately four hours and 48 minutes after the customer-facing impact began.

The report described a genuine symptom but did not, by itself, identify the underlying cause or establish that the problem affected the platform more broadly. Our support process assigned the case P4, and it did not trigger operational escalation.

Second customer report

A second customer contacted support at 21:46 CEST on 10 July with a related problem. This report was also classified as P4.

At this point, our processes should have correlated the two reports with each other, with the recent production change, with authentication failures, with automated access-blocking events, and with the simultaneous unavailability of several product areas.

That correlation did not occur.

The failure was ours. Customers cannot be expected to diagnose internal architecture or determine whether a symptom is isolated or platform-wide. Even where an initial description is brief, incomplete or ambiguous, our systems and personnel must recognise patterns across reports and operational data.

Escalation on 11 July

At 09:16 CEST on 11 July, a further customer email provided clearer information indicating a serious and potentially shared service problem.

The incident severity was escalated based on that information. Active technical troubleshooting with the customer began at 09:46 CEST.

At 09:53 CEST, we published a notice on the public meil.no status page informing customers that we were experiencing problems displaying email in the browser (webmail), that the incident was under investigation, and that IMAP and SMTP were operating normally so email could still be sent and received using standard email clients.

At 10:16 CEST, the root cause had been identified and the corrective change was being completed. The public status page was updated to state that the root cause had been identified and that work was underway to correct the issue. The affected services recovered at approximately the same time.

At 10:18 CEST, following verification, the incident was marked as resolved, with a note that we take the incident seriously and would conduct a subsequent root-cause review.

The approximately 30-minute period from active technical troubleshooting to service restoration demonstrates that the primary delay was not remediation complexity. The primary delay was failure to detect, correlate and escalate the incident earlier.

Support volume and classification

Our support operation handles a substantial daily volume of customer, automated and operational communications.

That volume is not an explanation or excuse for the incorrect classification. It is precisely why automated prioritisation, semantic analysis, cross-case correlation and human escalation procedures must be sufficiently robust.

The first and second reports should not both have remained at P4.

The public incident was created on the meil.no status page at 09:53 CEST on 11 July, seven minutes after active technical troubleshooting began.

The initial status message informed customers that:

• webmail was experiencing display and availability problems
• the incident was under investigation
• IMAP and SMTP continued to operate normally
• email could still be sent and received through standard email clients

The status page was updated at 10:16 CEST when the root cause had been identified, and the incident was marked as resolved at 10:18 CEST after service restoration had been verified.

The public incident record, "Problems displaying email in the browser", remains available on the meil.no status page via the status link on this report.

The status page provides operational communication during an active incident. This Trust Center report provides the retrospective analysis, including root cause, monitoring limitations, support-triage failures and corrective actions.

Cross-case correlation

We are improving automated correlation between incoming support reports.

A second independent report describing related symptoms within the same service area must materially increase the priority of the first report, even where neither report independently contains a complete technical diagnosis.

Semantic assessment of ordinary customer language

Customers should not be required to use technical terminology or identify the affected infrastructure component.

The systems used to assess incoming requests will be improved to recognise potentially serious symptoms described in ordinary language, including:

• email appearing to have disappeared
• webmail not loading
• several product areas being unavailable
• calendar and contact synchronisation failing
• the same account behaving differently in webmail and an email client

Correlation with operational context

Support cases will be correlated more closely with:

• recent production and security changes
• authentication-failure patterns
• automated access blocks
• synthetic monitoring results
• service logs and health signals
• similar reports from other customers

Priority-classification safeguards

Reports involving loss of access to core product functionality will require stronger justification before remaining at P4.

Multiple independent customer reports concerning the same service will trigger mandatory operational review.

Time-based escalation

Cases concerning inaccessible core services will receive time-based escalation where the reported symptom has not been verified or ruled out.

A low initial classification must not allow a potentially serious availability incident to remain unevaluated for an extended period.

Status-page initiation criteria

We are reviewing the criteria for publishing a public status incident.

Where multiple independent customer reports concern the same core service, or where an authenticated service check fails, the threshold for operational escalation and public status communication will be lower.

The initial network change, insufficient end-to-end monitoring, failure to correlate the first two customer reports and failure to escalate them beyond P4 were all within WAYSCloud's responsibility.

The information available in the earliest reports was limited, but responsibility for interpreting, correlating and escalating those reports remained with us.

Once the incident was actively escalated, our technical response and public status communication proceeded quickly. That does not offset the earlier delay.

We apologise for the interruption and for the length of time it took us to identify and restore the affected services.

Transparency requires us to report not only that customer data remained protected, but also where our operational monitoring and support processes failed.