✦ Preferences saved
HOSTINGER CASE FILE/PRESERVATION RECORD
TRACE / SPECIAL CASE FILE 003

PRESERVATION RECORD

The preservation and retention-hold chronology for the Hostinger case, including what was requested, what was recorded and what remained unconfirmed.

Preservation is tracked separately because a recorded request, an instruction sent internally and a hold actually applied are different states. The public record uses Hostinger’s own stated times and keeps later contradictions visible.

01

What was requested

The September 11 request sought preservation and retention hold for the new manager.php event records and for any retained original or quarantine object associated with the September recurrence.

02

What Hostinger confirmed was recorded

Human support stated that the explicit request had been forwarded and recorded in complaint #137820 at a Hostinger-stated time of 13:04. This establishes the complaint record of the request, not the technical application of a hold.

03

What remained unconfirmed

At 14:47 CEST, support said actual hold application had not been confirmed. At 17:40 CEST, the latest preservation statement in the supplied archive still did not confirm actual hold application, an internal hold reference or extended retention for any retained original or quarantine object.

04

The 17:02 and 17:33 conflict

At 17:02, a human agent said the explicit non-expiry instruction had not yet been sent. At 17:33, the same agent said it had been sent at 14:35 UTC, equivalent to 16:35 CEST. The contradiction is published as a chronological fact. The available material does not establish why the two statements conflict.

05

What the case file does not claim

The current record does not establish that the September object was destroyed after the request, that Hostinger refused preservation, or that any person intentionally allowed evidence to expire. Those propositions remain outside the factual claims published here unless new documentation establishes them.