Magento website down or showing a 503 error?

Follow the incident beyond the error page

Distinguish gateway failures and organise the evidence, recovery and order reconciliation.

• Magento 502 and 504 errors: follow the failed request
• A practical Magento incident response plan

Start with the scope of the outage

If your Magento website is down, the first useful distinction is whether the failure affects the whole store, a particular page or a transaction step. Capture what you can see before making changes. A precise symptom helps an engineer choose the next check; a series of unrecorded changes can make the incident harder to understand.

Check a small number of representative public pages from your normal browser. If appropriate, compare another device or connection once. Note whether the same failure affects the homepage, a product, a category and checkout. Do not repeatedly submit payments or run a large crawl against a struggling store.

If customers cannot trade, use the current emergency support service. Midoriweb confirms scope, availability and start time before payment. Submitting a request is not a guarantee that an engineer has accepted or begun work.

A 503 or 500 error is a symptom, not the diagnosis

A 503 Service Unavailable response means the responding server is not ready to handle the request. Maintenance and overload are common examples, but the response alone does not identify which component is responsible. It may be generated by the application or another service in front of it.

A 500 Internal Server Error is a general indication that the server encountered an unexpected condition. The visible page often cannot tell you the underlying cause. Relevant application and server logs, interpreted around the affected request and time, are usually more useful than the wording of a generic error page.

Keep the exact code and any non-sensitive request or report reference shown. Do not publish detailed stack traces or full logs in a public forum: they may contain internal paths or other information that should be reviewed privately.

If you see a certificate warning, a domain-resolution failure or a browser network error, record that wording too. Those observations are not interchangeable with an HTTP 500 or 503 and may require a different investigation path.

Build a short incident timeline

Write down when the store was last known to work and when the problem was first noticed, with a time zone. If you do not know the start time, say so. Distinguish a customer report from a failure you reproduced yourself.

List recent changes that may be relevant: a release, extension update, configuration edit, hosting maintenance, catalogue import or DNS change. Identify who made the change and whether there is a documented rollback. A recent event is a lead to investigate, not proof that it caused the outage.

Check the official status pages or notices for your hosting and relevant providers. A provider incident can help explain a dependency failure, but a green status page does not prove that your own integration or server is healthy. Supply the notice to the engineer alongside the actual storefront evidence.

Keep one shared record of actions and outcomes. When several people are involved, agree who is coordinating technical changes. Two independent “quick fixes” applied at once can complicate recovery and make it harder to know what restored service.

Do not force a store out of maintenance blindly

Magento has a maintenance mode used during work on an installation. If a maintenance page appears after a deployment, establish whether that work completed successfully and whether the store is ready to serve traffic. Removing a flag simply because it exists is not a recovery plan.

The technical team should examine deployment output and the current application state before reopening the store. A failed upgrade or incomplete release may require a controlled correction or rollback. The right action depends on what changed and the state of the database and files.

Adobe documents the maintenance-mode mechanism. This guide deliberately focuses on incident decisions rather than giving a command to run on an unknown live installation.

A capacity problem needs similar care. Restarting services may change the immediate symptom without explaining the underlying issue. Record the evidence, use an authorised engineer and agree what success will look like before treating a temporary recovery as a resolved incident.

Protect orders and payments during recovery

A working homepage does not establish that customers can complete purchases. Conversely, a missing confirmation page does not establish that a payment failed. If checkout is affected, an authorised team member should reconcile Magento order state with the payment provider before asking a customer to retry.

Do not restore an old database as a casual troubleshooting step. It can discard orders, customer changes or other activity recorded after the backup. Any recovery involving data needs an explicit assessment of what will be lost, what can be recovered and how payment records will be reconciled.

Keep customer and card details out of the initial incident description. Provide a secure reference to the affected transaction through the agreed support process when requested. Our Magento checkout and payment support page explains this area of work.

If checkout is functioning but slow, use the slow-checkout diagnosis guide. A planned performance investigation and an active trading outage have different priorities.

A useful emergency handover checklist

Keep the initial request brief enough for someone to understand the incident quickly. Include:

• Store and affected area: the public website address and whether the whole store, catalogue, Admin or checkout is affected.
• Visible symptom: the exact error, a safe screenshot and one or two affected URLs.
• Time: when it was noticed, last known working time and time zone.
• Trading impact: whether orders are blocked, only some shoppers are affected, or staff cannot process work.
• Recent changes: deployment, module, configuration, hosting or provider events that may help narrow the investigation.
• Actions already taken: what changed, who changed it and the observed result.
• Available technical contact: who can authorise work and arrange the required access.

Do not include passwords, secret keys or an unreviewed database export. Midoriweb requests suitable access through the secure access workflow after acceptance, rather than through ordinary email or the initial message.

Verify recovery beyond the homepage

Agree a proportionate recovery check with the engineer. It should cover the affected journey, relevant customer states and the systems involved in completing it. Payment verification must use an agreed method; do not create repeated real charges merely to test a page.

Record what restored service, what evidence remains uncertain and whether a temporary measure is still in place. Decide who will observe the next trading period and what would trigger further action. Recovery is a useful milestone, but root-cause work may remain after customers can use the store again.

Where the incident exposed recurring slow responses or resource pressure, a separate Performance Investigation can help prioritise follow-up work. It does not replace urgent incident handling or promise that the same problem can never recur.

Technical references

See the HTTP definitions of 503 Service Unavailable and 500 Internal Server Error. A status definition explains the response category; the installation’s evidence establishes the cause.