An administrator added a redirect rule to a shared .htaccess file in a parent folder, which three sites inherited. The syntax was nearly right, with a missing flag. Precisely, the list of flags at the end of the rule had lost its opening bracket, and Apache does not guess what you meant.
All three sites returned 500 errors immediately. The error log named the file and line, but he was working from a phone and spent forty minutes assuming the problem was elsewhere.
Restoring the previous version of the file ended it. A test on a single site first would have shown the error in seconds. The people involved here are composites, but the pattern, one small edit with a wide blast radius, is among the most common causes of a sudden multi-site outage on shared hosting.
How one file reaches three sites
On Apache, an .htaccess file is a per-directory configuration file. It applies to the folder it sits in and to every folder beneath it, unless a deeper file or the server's own settings override it. This is intentional. It lets you put a rule once, near the top, and have it cover everything below.
On this account, the agency that ran three small sites (a bakery, a plumbing firm and a local club) kept them as separate folders under one parent, each added to the hosting plan as its own domain:
/home/agency/public_html/ <- .htaccess edited here
/home/agency/public_html/bakery/ (bakery.example.com)
/home/agency/public_html/plumbing/ (plumbing.example.com)
/home/agency/public_html/club/ (club.example.com)Each domain pointed at its own folder, and each folder also had its own .htaccess. Apache reads them from the top down and merges the lot. A broken directive in the parent file therefore breaks every request below it, before the child files are even considered.
The edit
The agency had been asked to send all visitors using the old plain-HTTP addresses and the bare domain names to the canonical HTTPS address with www. Doing it once in the parent seemed tidier than three times. The administrator opened the file in the control panel's editor on his phone, while away from his desk, added a block, saved it and moved on.
The rule he meant to write was along these lines:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]What got saved had the final part as R=301,L], with the opening bracket missing. On a phone keyboard in a small editor window that is an easy slip, and the error was not visible without scrolling sideways. Apache's module for rewriting reads that as a malformed flag list and refuses to process the file.
The rule also had a design flaw that would have mattered afterwards. It prefixed www. to whatever host name came in, which turns www.bakery.example.com into www.www.bakery.example.com. A test would have shown that too.
Forty minutes on the wrong trail
| Time | What he thought | What he did |
|---|---|---|
| 0 min | Saved the edit, sites seem slow | Reloaded one site; got a plain "Internal Server Error" |
| 5 min | Hosting outage? | Checked the provider's status page: all green |
| 12 min | PHP problem after an update? | Looked at PHP versions in the panel, changed nothing |
| 20 min | Plugin or caching fault? | Disabled a cache plugin on one site; still 500 |
| 30 min | Account was suspended? | Contacted support chat, waited |
| 40 min | Opened the error log, finally | Saw the .htaccess line named in the message |
Three sites failing at the same moment points to something they share, which is the server, the account, or a file they all read. He had recently changed exactly one such file, and it was the last thing he considered. When you change something and the symptom begins in the same minute, the change is the first suspect, not the last.
What the error log said
The log entry had been there since the first failed request. In the panel it was under "Errors", and over SSH it lives in a path that depends on the host, often ~/logs/error.log or the Apache default. The relevant lines looked like this:
[Mon Oct 05 10:12:44.123456 2026] [core:alert] [pid 4121] [client 203.0.113.9:51234]
/home/agency/public_html/.htaccess: RewriteRule: bad flag delimitersIt names the file and the directive. That is more than most errors give you, and it also explains why the browser says nothing useful: a 500 page deliberately hides details from visitors. The log is where the detail goes.
The fix, and the slower fix
The quick fix was to restore the previous version of the file. The panel's file manager kept no history, but the administrator had pasted the old content into a message earlier in the week, and the host's nightly backup also had it. Putting the old content back returned all three sites to normal within a minute of the decision.
The better fix came later at a desk. He put the corrected rule in the bakery's own .htaccess only, with the bracket restored and the www prefix handled properly, tested it, and then repeated it for the other two sites. The redirect generator produces rules of this kind, and the status code list explains the 301 and 500 codes involved.
A safer way to edit
Take a copy first, from a shell if you have one:
cp -p .htaccess .htaccess.bak-$(date +%F)Make the change in the narrowest place that works, which means the one site's folder, not the parent. Load the page at once and watch the log in a second window:
tail -f ~/logs/error.logA 500 within a few seconds of saving means the edit is at fault. Note that checking the web server's configuration with apachectl configtest does not read .htaccess files, so it will not catch this class of mistake. Only a request does. Avoid editing from a phone if you can, and if you cannot, keep the old content in a note you can paste back.
Other ways a small edit gives a 500
The missing bracket is one of several mistakes that produce the same blank error page. If you meet a 500 after touching this file, these are the usual suspects, and the error log tells them apart:
| Mistake | Typical log message |
|---|---|
| Directive from a module not loaded on the server | Invalid command, perhaps misspelled or defined by a module not included |
| Malformed flags or missing arguments | RewriteRule: bad flag delimiters, or wrong number of arguments |
| Rule that rewrites to itself with no stop flag | Request exceeded the limit of 10 internal redirects |
| PHP settings placed where the server runs PHP as CGI or FPM | Invalid command php_value |
| Stray character from a word processor or phone keyboard | Unknown directive or syntax error at the first odd line |
The last row is more common than it sounds. Smart quotes, a non-breaking space and a trailing line ending that the editor invented can all turn a good rule into a bad one while looking identical on screen.
The aftermath
The outage lasted about forty-five minutes in the middle of a weekday morning. The bakery missed some online pre-orders for that day's collection, the plumbing firm's contact form was unavailable while a customer was trying to book an emergency call-out, and the club's treasurer, who was updating the subscription page, lost an unsaved draft. Nobody lost data, but the plumber phoned.
The agency changed its way of working afterwards. Redirect rules for the canonical address now live in each site's own file. The parent file contains only settings that really apply to everything, and it has a comment at the top saying so. Edits are made from a desk, with the log open, and the old version is kept in a dated copy beside the live file.
What would have caught it
- Keep a copy of a configuration file before editing.
- Change one site first, and check the log.
- Know which settings are inherited from parent folders.
- Open the error log at the first sign of a 500, before forming theories.
- Make configuration changes at a keyboard, not on a phone, unless it is an emergency.