Site en panne : la marche à suivre en cas d'incident

What to do when your site goes down? The reflex is often panic, followed by waiting. However, the first few minutes are crucial: distinguishing an infrastructure failure from an error in your application, checking the status page, and opening a ticket can accelerate recovery. Here is the step-by-step procedure.

Distinguishing application failure from infrastructure failure

The first thing to do is to locate the failure, as the two situations are not handled in the same way:

• Infrastructure failure: the server or network is at fault. Your site is inaccessible, but so are your emails or other services hosted on the same server. It is the provider's responsibility to intervene.
• Application failure: the server is running, but your site displays an error — often following an update, a faulty extension, or a code issue. Resolution is generally your responsibility.

To decide, test from the outside: does the site respond? Are emails arriving? An online monitoring tool allows you to check access without going through your own connection, which may itself be the cause. This distinction prevents you from waiting for the provider's action for a malfunction that actually relates to your application.

Checking the status on the status page

Before opening a ticket, check your provider's status page. It announces ongoing incidents on the infrastructure: it is the fastest way to know if the failure is general or specific to your service.

A rigorous status page indicates, for each incident: the affected scope, the start time, and the progress status. At Atlas Hoster, the Service Status page is fed by monitoring and reports every incident; a written report is provided after any major incident lasting more than thirty minutes or having a customer impact. If the page reports nothing, the failure is likely specific to your site.

Opening and following a ticket

If the failure concerns you, open a support request without delay. A precise ticket speeds up processing:

• describe the symptom precisely: which page, which error, since when;
• indicate what you have already checked;
• attach any useful screenshot or error message.

Once the ticket is open, follow it: answer support questions and check the progress of interventions. The procedure is described in Open a support request and Follow, answer, close or reopen a request.

What the response time covers

Depending on your plan, the provider commits to response times: the GTI (Guaranteed Response Time) and GTR (Guaranteed Resolution Time). These times run from the monitoring alert or the opening of your ticket.

They apply to infrastructure and managed services, but do not cover failures related to your own configuration or content, which are explicitly excluded from commitments. Knowing these limits prevents you from waiting for a guaranteed resolution on a problem that relates to your application. The details of the timeframes and exclusions are specified in SLA and 99.9% Availability.

If your plan includes an on-call service, the time runs at night and on weekends, not just during business hours.

The post-incident report

After a major incident, a serious provider provides a written report: what happened, the corrective actions taken, and the measures planned to prevent any recurrence. This document is valuable:

• it allows you to understand whether the cause was avoidable;
• it documents the incident for your own internal tracking;
• it justifies, if applicable, a credit claim provided by the SLA.

Read it carefully and ask questions if the root cause is not clear. A closed incident without a report should alert you.

What to do when your site goes down: the checklist

To not forget anything in an emergency, keep this list handy:

1. Test the site from the outside, not just from your local network.
2. Check if the server's emails and other services are responding.
3. Check the provider's status page.
4. Open a ticket describing the symptoms precisely, with screenshots if possible.
5. Follow the ticket and answer the technical team's questions.
6. Upon resolution, read the incident report.

Save this list: the day the site goes down, you will not have time to reconstruct it.

Preventing failures: backups and redundancy

The best way to handle a failure is to prepare for it in advance:

• Up-to-date and verified backups: in case of data loss, restoration must be possible and fast. See Create a backup copy.
• Redundancy: a single server constitutes a single point of failure; a redundant architecture survives the failure of a component.
• A recovery plan: a clear organization defining roles and response times, documented in advance. See Disaster Recovery Plan.

These measures do not eliminate all failure risks, but they reduce their duration and impact, turning a critical incident into a simple operational formality.

To build a complete backup strategy, see Backups: the 3-2-1 strategy.

To summarize

When your site goes down, act methodically: locate the failure, check the status page, open a detailed ticket, ensure its follow-up, and then study the report. Finally, anticipate future incidents thanks to regularly tested backups and redundant infrastructure.

To monitor the status of services and be notified of incidents, check the Atlas Hoster status page.

Frequently Asked Questions

How do I know if the failure is from me or the host? Check the status page: if it reports no incidents, the failure is likely specific to your site. Also test your emails and site access from another network connection.

What is the response time? It depends on your plan and the type of failure. In managed services, the committed GTR ranges from best effort to 2 hours depending on the tier subscribed. Failures related to your own configuration are excluded.

What should I do if I have no backup? First resolve the current failure with support, then immediately set up regular and verified backups: a technical incident without a backup can lead to the permanent loss of your data.