# Security advisories and maintenance This page tells you, before you book, how fast Hangar acts when a vulnerability or an advisory appears. | Trigger | What Hangar does | Within | |---|---|---| | An ASD or ACSC advisory, or a vendor advisory, for a vulnerability that is exploited or critical in the image, the driver, the runtime or the control plane | Rebuilds and releases the image or the service; ends the affected instances if the advisory requires it | 48 hours | | Any other vulnerability in those components | Rebuilds and releases | 14 days | | An advisory that requires Hangar to take a tier or the whole service offline | Posts the advisory reference on the status page, credits affected bookings in full, keeps the checkpoints and certificates issued to that point, and emails customers | Status page within 1 hour of the decision; email within 4 hours | | A threat detection finding from Amazon GuardDuty on a machine that serves a slot | Records the finding with every update, and an operator decides it as one item: the job continues or stops, and the customer reads the decision in one sentence | Within 1 hour | | A vulnerability reported to Hangar (security.txt) | Acknowledges the report, assesses it, fixes it on the timings above and tells the reporter | Acknowledged within 1 business day | | Planned maintenance that stops a tier | Announces it on the status page and by email, outside every sold slot | 7 days ahead | Hangar matches each advisory against the whole package names in the software bill of materials of every promoted image, service and CLI release. The clock of an advisory starts when the advisory arrives, and the advisory closes only with the action taken on the record. Each instance serves one slot and is then replaced. A release therefore reaches every slot in the next block. This page also lists the advisories that Hangar has acted on, with dates, and the maintenance calendar.