Drupal site repair.
White screen of death, 500 error, a hacked site, a failed update, or a Drupal install nobody has touched in years. Diagnosis within 24 hours, a quote before any work starts, no retainer required.
24h
Typical time to diagnosis
$0
Quote
7→11
Drupal versions I repair
Six situations I know from practice.
White screen instead of a site
The site does not load at all, or shows a blank page — usually after a module update, a PHP version change on the host, or memory exhaustion. Drupal hides the cause; it has to be read from the logs.
500 or 503 error
The server responds, but Drupal cannot render the page. The usual causes: a module incompatible with the core version, a corrupted cache, a dependency missing after a Composer update.
Failed update
A core or module update stopped halfway, drush updb throws an error, part of the site works and part does not. Rolling back without a backup can be worse than finishing the update — that has to be assessed before anything is touched.
Hacked site
Replaced content, redirects to foreign domains, spam in Google results, a browser warning. Removing the symptoms is not enough — the hole someone came through has to be found and closed.
Database error
A message about a lost connection, a corrupted table, or an exceeded limit. Sometimes a hosting failure, sometimes the result of a failed migration or a full disk.
A site nobody has updated
Drupal 7, 8 or 9 without support, dozens of pending updates, modules with no successors. It still works, but every security advisory is a public how-to for breaking into it. Here repair means catching up — or deciding on a migration.
From report to working site.
01
Diagnosis — within 24 hours
I get access to the hosting and the admin panel (or just the logs, if the panel is down). I check the Drupal version, error logs, module state, backups, and traces of intrusion. Nothing is changed on production.
02
Quote before work
You get a description of the cause, the scope of the repair, and an estimated number of hours. If there are several routes — restoring from backup versus finishing the update, say — I describe both with their risk and cost. You decide.
03
Repair
Work on a copy of the site where possible, then on production. Afterwards I check the site as a user would: forms, login, main pages, language versions.
04
Hardening and report
Closing the hole, applying critical security updates, a working backup. Finally a short report: what caused it, what was done, and what is worth doing next so it does not happen again.
Hourly billing, quote before work.
A repair is a one-off job, not a retainer. Diagnosis is free; work is billed hourly, and you know the number of hours before anything starts. Typical ranges from my jobs:
White screen, 500 error, corrupted cache
1–3 hoursusually
- Whether the cause is in the logs or has to be hunted down
Failed core or module update
2–6 hoursusually
- Whether there is a pre-update backup
- How many custom modules
Hacked site
4–12 hoursusually
- Extent of the infection
- Age of the install
- Whether a clean backup exists
Catching up on missed updates (Drupal 8/9/10 → 11)
6–20 hoursusually
- Number of modules and their state
- Whether the modules have successors
Hourly rate: $50. For large backlogs or Drupal 7 I propose a fixed price — or a migration, if a repair no longer makes sense. Invoices are issued in PLN; USD prices include a buffer for exchange-rate fluctuations. If the site is then to go under ongoing care, the repair cost is credited against the first month of the plan — details on the Drupal maintenance page.
Before you write: what to do in the first hour.
- Do not fix blind. Re-running the update, restoring a random backup, removing modules to see what happens — each of these can erase the trace of the cause and make the repair harder. If a hacked site is still running, do not clean it yourself: the traces are needed to find the hole.
- Secure what is there. If you have hosting access, take a backup of the files and database in their current state — even broken. A copy of a broken site beats no copy.
- Gather the access details. Hosting panel, FTP or SSH, database, a Drupal admin account, the domain registrar. Without them the diagnosis waits, and with a hack, time matters. If the previous contractor holds the passwords, start by recovering hosting access — that is usually enough.
So this is the last time.
Most of the failures I repair share one cause: nobody updated the site and nobody tested the backups. After the repair you get a list of what is worth doing — and you can do it yourself. If you would rather someone did it on a steady schedule, ongoing technical maintenance starts at $60 a month and covers updates, backups, and monitoring.
Frequently asked questions.
How much does a Drupal site repair cost? Diagnosis is free; work is billed hourly after a quote. Typical failures — white screen, 500 error — take 1–3 hours; a hacked site 4–12 hours; catching up on years of missed updates more, in which case I propose a fixed price.
How fast can you fix the site? I diagnose within 24 hours of receiving access, usually sooner. Simple failures are fixed the same day; a hack or an update backlog takes one to several days, depending on the state of the site.
Will you repair a site someone else built? Yes — that is most of my repair work. I need access to the hosting and the Drupal admin panel; documentation from the previous contractor helps but is not required.
My site has been hacked — what first? Do not clean it yourself and do not restore a random backup. Back up the current state, change the hosting and admin passwords, gather the access details, and write to me. The traces of the intrusion are needed to find and close the hole.
I am on Drupal 7 — can it still be repaired? It can be brought back to life, but Drupal 7 no longer receives security support. A repair makes sense as a stopgap; the long-term answer is a migration to Drupal 11.
Do I have to buy a maintenance plan after the repair? No. A repair is a one-off job. You get a report listing what is worth doing next — and you can do it yourself, with another contractor, or with me.
Do you work with clients outside Poland? Yes. I work remotely with clients across Europe and beyond, in English, with invoices in PLN at USD prices that include a buffer for exchange rates. Time zone: CET.