Urgent Website Support: What to Do in the First Hour

A practical first-hour runbook for anyone whose website is down, degraded or defaced right now, covering triage, diagnosis, evidence preservation and restoring service safely, written for IT managers, marketing leads and agency owners who need urgent website support.

Most website outages are made worse in the first thirty minutes. Someone restores a backup over the top of a compromised server and destroys the evidence. Someone flushes the CDN cache while the origin is still returning errors and pushes the failure to every edge location. Someone reboots the box, the symptom disappears, and it returns four hours later during peak traffic because nobody found the cause.

The sequence below is the order of operations we follow on incidents. Work through it rather than jumping to the fix you assume is required.

Before You Do Anything: Establish What Is Actually Broken

"The website is down" is a report, not a diagnosis. Before touching anything, answer four questions and write the answers down with timestamps:

• Is it down for everyone, or for you? Test from a mobile connection off the corporate network, and from an external checker. A corporate DNS resolver or a firewall rule can produce a convincing but entirely local outage.
• What is the actual HTTP response? Run curl -sSI https://yourdomain.com.au. A 500 is an application error. A 502 or 504 means something in front of the application cannot reach it or is waiting on it. A 403 is often a WAF rule. A connection timeout with no status code at all is a network, DNS or firewall problem, not an application one.
• What changed? Deployments, plugin or module updates, DNS edits, certificate renewals, firewall changes, a new WAF rule, a database migration, a password rotation, an expired credit card on a cloud account. Most incidents follow a change within the previous 48 hours.
• Is anything else affected? Email, the CRM, the payment gateway, a second site on the same server. Shared symptoms point to shared infrastructure.

Triage in the First Ten Minutes

1. Capture the exact error the public sees, with a screenshot and the full response headers. This is your baseline and your evidence.
2. Check whether the origin server is reachable independently of the CDN, by requesting it on its IP address with a Host header, or via a staging hostname that bypasses the proxy.
3. Check certificate validity and expiry: openssl s_client -connect yourdomain.com.au:443 -servername yourdomain.com.au.
4. Check DNS resolution from an authoritative nameserver and from a public resolver: dig yourdomain.com.au A +trace and dig @1.1.1.1 yourdomain.com.au.
5. Log in to the server and check disk, inodes, load and memory before you look at application code.
6. Tail the web server and application error logs and note the first occurrence of the error, not the most recent one. The first occurrence tells you when the incident actually began.
7. Decide the severity, tell stakeholders what you know and what you do not, and give them a time for the next update rather than a time for the fix.

Symptom to Cause: Reading the Failure Correctly

DNS, TLS and CDN Failures That Look Like Application Failures

DNS

A registrar auto-renewal failure, a nameserver change made by a third party, or a DNSSEC mismatch will take a site offline completely while the server sits there healthy. Check the domain expiry date, the delegated nameservers, and whether the A or CNAME records still point at the current origin or CDN. If a record was changed, remember the previous TTL governs how long the old value lingers in resolvers.

TLS

Certificate expiry remains one of the most frequent avoidable outages, usually because an automated renewal has been failing silently for weeks. A renewal will fail if the HTTP-01 challenge path is blocked by a redirect rule, if a WAF challenges the certificate authority's request, or if the DNS API credentials used for DNS-01 have been rotated. Check the renewal log, not just the expiry date. If you are behind Cloudflare, a 526 means the edge does not trust the origin certificate, which is a different problem from a public expiry.

CDN and WAF

Cloudflare's 5xx family is diagnostic: 521 means the origin refused the connection, 522 means it did not answer within the timeout, 523 means the origin is unreachable at the network level, and 525 or 526 are TLS handshake failures between edge and origin. These point at the origin or the network path, not at your code. Equally, a new firewall rule or a managed ruleset update can start blocking legitimate traffic, form submissions or an integration's API calls. The event log at the edge will show a rule ID against every blocked request, which is the fastest way to confirm or eliminate the WAF.

Server-Level Diagnosis

Work from the bottom of the stack upwards. In rough order of frequency:

• Disk and inodes. df -h and df -i. A full /var caused by log growth, an unrotated debug log, session files or database binary logs will produce write errors that surface as 500s. Inode exhaustion presents as a full disk that reports free space.
• Memory and the OOM killer. free -m and dmesg -T | grep -i oom. If the kernel killed MySQL or a PHP worker, the application error is a symptom, not the cause.
• Process pools. For PHP-FPM, compare active children against pm.max_children in the pool config. Requests queue silently once the pool is saturated, which the user experiences as a 504.
• Database connections. SHOW PROCESSLIST and SHOW STATUS LIKE 'Threads_connected' against max_connections. One unindexed query behind a newly published page can hold enough connections to lock out the whole site.
• Scheduled tasks. An overlapping cron or queue worker, especially an import or reindex, will consume every available resource on a schedule. Recurring outages at the same minute past the hour are almost always cron.

Signs of Compromise, and Why You Should Not Restore Yet

Stop and treat the incident as a security event, not an outage, if you see any of the following: PHP files inside an uploads directory, files modified at a time nobody deployed, an administrator account you do not recognise, unexpected outbound connections, obfuscated code appended to index.php or a theme or template file, injected spam content in database rows, new cron entries, or a sudden spike in outbound mail.

Restoring a backup at this point is the wrong instinct. If the entry point was a vulnerable component or a stolen credential, the restored site is compromised again within hours, and you have overwritten the evidence needed to work out how they got in. You also cannot tell your board, your insurer or your customers what was accessed. Where personal information may have been exposed, that determination has legal consequences under the Notifiable Data Breaches scheme, and it is difficult to make once the disk is gone.

Preserve Evidence Before You Remediate

• Take a snapshot or image of the volume before changing anything on it.
• Copy web server access and error logs off the server immediately, before rotation deletes the window you need.
• Export CDN and WAF logs, which often retain the request that succeeded when the origin logs do not.
• Record a timeline in a single timezone, with the first known good and first known bad timestamps.
• Rotate credentials off the compromised host: CMS administrators, database users, SSH keys, API tokens, deployment secrets and any shared passwords.
• Isolate rather than delete. Take the site to a maintenance page or restrict it to known IP addresses while you work.

Restoring Service: Roll Back, Restore or Fix Forward

Once you know the cause, choose deliberately. Rolling back the last deployment is the fastest option when the incident began at a release and the database schema has not changed. Restoring from backup is appropriate for data loss or content damage, and its cost is every change made since the snapshot, which is why the recovery point matters as much as the recovery time. Fixing forward is right when the fault is a single configuration value, a certificate, a firewall rule or a query, and the fix is understood and small.

Whichever you choose, verify against the origin before clearing the CDN cache, confirm forms, logins, checkout and any integration that touches the fault, and keep monitoring in place for at least an hour afterwards. Silent failure of a background process is common after a restore.

When Your Vendor Is Not Answering

The most common reason an outage runs for days is not technical. It is that the hosting provider will not touch the application and the web agency has no access to the infrastructure, so each refers you to the other. If you are in that position, get three things in front of whoever helps you next: registrar and DNS access, server or cloud console access, and the code repository. With those, a competent team can act. Without them, everyone is guessing.

If your contract carries response commitments that were not met, record the times you notified the vendor and the times they responded, because that record is what makes the conversation about a breach of your service level agreement a factual one. Where an incident is live and unowned, emergency break/fix engagement exists precisely to put someone on it now, independent of whoever built the site.

Incident Severity and Expected Response Compared

Severity should be defined in writing before an incident, along with who can declare a P1, what hours the commitment covers, and how updates are communicated. Arguing about priority during an outage costs time nobody has.

After the Incident: Root Cause and Preventing a Repeat

Within a few days of service being restored, produce a short written record: what happened, when it was detected, how it was detected, what the cause was, what was done, and what will change. Detection is the part most organisations skip, and it is usually the biggest opportunity. If a customer told you before your monitoring did, external uptime and transaction monitoring is the cheapest improvement available.

The other durable fixes are unglamorous: patch the components that were out of date, add alerting on disk, memory and certificate expiry, verify that backups restore rather than merely run, remove administrator accounts nobody uses, enable multi-factor authentication, and put a repeatable deployment process in place so rollback is a command rather than an improvisation. Ongoing security monitoring and patch management exists to make the next incident smaller, or to make sure there is no next incident of the same kind.

Frequently Asked Questions

What should I do first when my website goes down?

Confirm the outage from outside your own network, then capture the exact HTTP response with a tool such as curl so you know whether you are dealing with a timeout, a 5xx from the server, or a block from a firewall. Note what changed in the previous 48 hours. Do not restart services or restore backups until you have recorded the error and the time it started.

Can I get emergency website support in Australia if I am not an existing client?

Yes. Emergency break/fix support is offered as a standalone engagement for organisations whose current provider is unavailable or unable to resolve the issue. What is needed to start is access: DNS and registrar, the server or cloud console, and the code repository. Many organisations move to an ongoing support agreement afterwards, but that is not a condition of getting help during the incident.

Should I restore a backup if my site has been hacked?

Not immediately. Restoring overwrites the evidence needed to identify how the attacker gained access, and if the entry point is still open the site will be compromised again quickly. Take a snapshot and copy the logs off the server first, rotate every credential, identify and close the vulnerability, then restore to a clean environment.

What counts as a breach of a website SLA?

A breach occurs when the provider fails to meet a commitment written into the agreement, most often the response or resolution time for a given severity, or the monthly uptime percentage. To rely on it you need dated evidence: when you notified them, through the agreed channel, and when they actually responded. Independent uptime monitoring is far more persuasive than the provider's own dashboard.

Why does my host say the server is fine when my site is clearly broken?

Because both statements can be true. Hosting providers typically monitor the machine, not the application, so a healthy server running a crashed PHP process, an expired certificate or a fatal error after a plugin update is still "fine" by their measure. Resolving it requires someone with both infrastructure access and the ability to work on the application code.

How quickly should a critical website incident be acknowledged?

For a genuine P1 affecting all users or involving a security event, acknowledgement should be immediate and an engineer should be actively working within the response window defined in your agreement, including outside business hours if your agreement covers them. Just as important is the update cadence: a fixed interval for status updates until service is restored, even when the update is that work is continuing.

Emergency Support and Ongoing SLAs from UnDigital

UnDigital runs infrastructure and the development capability to act on it, which is why our incidents do not stall at the boundary between the host and the site. We take on live incidents through break/fix emergency support, and we hold ongoing responsibility for enterprise and government websites under defined support SLAs covering monitoring, patching, backups, security and response times. If your website is critical to sales or lead generation, the aim is to make outages rare, short and explainable.

If you are in an incident now, call. If you are reading this after one, the conversation worth having is about what happens the next time.