Approved scope only
Access is used for the support task you asked us to investigate.
Independent Linux server support
Linux Server Support With Evidence Before Changes
When your site is down, a service will not start, or the load spikes and nobody knows why, we investigate the whole stack and explain what is actually wrong in plain language. We work on servers hosted anywhere — with another provider, on your own infrastructure, or in a client account — and you do not have to be a hosting customer of ours.
You do not need to host with usThis is a paid engineering service, open to anyone. We work on your servers and sites wherever they run — another hosting provider, your own hardware, or a client's account.
- Diagnose before major changes
- Approval before repair
- Third-party infrastructure welcome
- Temporary access supported
Followed a server troubleshooting guide and the issue still persists? Send us what you found. We can continue the investigation without making you repeat every step.
production-diagnostic controlled scope
$ investigate --before-change
01
ObserveCapture symptoms, logs, and current state
02
IsolateTrace the failure across the relevant layers
03
ExplainReport cause, risk, scope, and repair path
04
ApproveNo broader repair before your go-ahead
Change policyLeast-change
Customer controlRetained
Final outputVerified report
LinuxOS & services
Web stackNginx, Apache & PHP-FPM
EmergencyOutage troubleshooting
Any providerVPS, cloud & dedicated
Access & operational safety
Your server access is treated like production access.
Credentials are not a blank cheque to alter your infrastructure. We agree the task, use only the access needed to investigate it, and keep unrelated configuration outside the scope.
You retain controlUse a temporary account or key where practical, then revoke it and rotate shared credentials after completion.
Diagnosis before disruption
We gather evidence and avoid major changes until the path is understood.
No unrelated changes
Existing security and application settings stay untouched unless they are part of the approved repair.
Clear change boundary
Additional work, risk, or scope is explained before you authorise it.
Close access cleanly
We recommend credential rotation and removal of temporary accounts or SSH keys.
Problems we solve
Troubleshooting across the whole stack
A visible error is often one layer away from the real cause. We follow the evidence from browser to application, service, operating system, network, and storage.
01
Linux & server
Work out why a server that was fine last week is now refusing connections, running out of memory, or filling its disk with logs nobody is reading.
- Out of memory and OOM-killed services
- Disk and inode exhaustion
- Permissions and ownership after a migration
- Failed services and boot problems
- CPU load with no obvious cause
02
Web stack
Follow a 500 or 502 back to whatever actually produced it — the web server, the PHP pool, or the application — instead of restarting services and hoping.
- Apache and Nginx configuration
- PHP-FPM pool exhaustion
- 502 and 504 under traffic spikes
- SSL termination and redirect loops
- Virtual host and reverse proxy setup
03
Database & storage
Find the queries, locks, or capacity limits that make a site crawl during your busiest hours while the server looks idle the rest of the day.
- MySQL and MariaDB won't start
- Slow queries and table locks
- max_connections errors under load
- Corrupted tables and repair
- Backups that have never been test-restored
04
Network, DNS & email
Trace where a request or a message actually stops — at the DNS record, the firewall, the mail server, or the receiving provider.
- Website and email DNS records
- Mail landing in spam at Gmail
- SPF, DKIM and DMARC records
- SMTP delivery failures and bounces
- Certificate and hostname mismatches
Migration & recovery
Move websites, VPS workloads, or complete server environments with a defined plan.
We can assess dependencies, DNS, databases, files, mail, services, and validation steps before a migration or recovery change begins.
A controlled support process
Know what happens before anyone touches production
The process separates investigation, approval, repair, and verification so you never lose control of the environment.
- 01
Tell us what broke
Describe what you are seeing, when it started, and anything that changed just before. You do not need to know the cause — that is the part we are being paid for.
- 02
We agree what access we need
We tell you the minimum access required and why. Temporary credentials are fine, and if your host restricts what we can reach, we say so before starting rather than halfway through.
- 03
We investigate before we change anything
We read the logs, the configuration and the running state first. Nothing on a live server is altered while we are still working out what is wrong.
- 04
You get the cause in plain language
You receive what failed, why, what fixing it involves, and what it costs. Written so a founder or a developer can act on it, not only a sysadmin.
- 05
You approve, we repair and verify
After your approval we apply the fix, test the workflow that was actually broken, and tell you exactly what changed. Work that touches live traffic is scheduled around the system's measured low-traffic window.
Access is reversible. Provide temporary credentials when possible, retain your own administrator access, and rotate shared credentials after the work is complete.
Start a support requestAnonymised technical example
A write failure that wasn’t a conventional permission error
An application deployment could not write to its release path even though the file owner and conventional permission modes appeared correct.
Root causeA server-side SELinux context mismatch prevented the web process from writing to the required path.
- The issue was corrected within the server’s existing SELinux security policy.
- The website remained online during the focused repair.
- Unrelated permissions and server settings were not changed.
- The result was verified and documented for future reference.
evidence.logread-only inspection
$ ls -ldZ wp-content/upgrade
system_u:object_r:default_t:s0
$ matchpathcon wp-content/upgrade
system_u:object_r:httpd_sys_rw_content_t:s0
finding DAC permissions valid
finding MAC context mismatch isolated
scope restore expected context only
Update path verifiedExisting security policy preserved
Support that fits the problem
One-time repair or ongoing Linux server management
Start with the issue in front of you. If the environment needs recurring care, we can define a separate management scope afterward.
Focused engagement
One-Time Technical Support
For a defined issue that needs diagnosis, repair, migration, or recovery assistance.
Best for- Website or service outages
- Specific Linux or web-stack errors
- Migrations and configuration work
- Emergency troubleshooting
Continuing partnership
Ongoing Linux Server Management
For servers that need recurring administration and a consistent technical owner.
Best for- Regular maintenance and administration
- Monitoring and proactive support
- Performance and security assistance
- Recurring operational work
Why Hostaccent
Infrastructure thinking, not checklist troubleshooting
Hostaccent works across hosting, VPS, dedicated servers, and production web stacks. That matters when an application symptom actually begins in PHP-FPM, MySQL, DNS, storage, networking, or the operating system.
Server-level investigation
Production-safe change discipline
Clear findings and repair scope
Support for infrastructure hosted elsewhere
Supported environmentsCommon platforms and services
AlmaLinuxUbuntuDebianRocky LinuxcPanel / WHMPleskApacheNginxPHP / PHP-FPMMySQL / MariaDBsystemdVPS / Dedicated / Cloud
Platform versions, provider limitations, and available access are reviewed before scope is confirmed. No official partnership is implied.
The Hostaccent support ecosystem
One technical partner. Ten specialist paths.
A server symptom rarely stays on one layer: downtime can begin in the web server, PHP-FPM, MySQL, the firewall, DNS, storage, or a failed system service that only shows up under load. Explore every specialist service without losing the wider production context.
Not sure which service matches?Tell us what is failing and when it started—we will start at the layer that produced it.
Request technical supportBefore you request support
Questions about access, approval, and scope
Clear boundaries make production work safer. These are the practical answers most customers need before opening a request.
Ask a different question01Do I need to be a HostAccent hosting customer?
No. This is a paid service that works on authorised servers with other hosting providers, on customer-owned infrastructure or in a client's account. You do not need to move hosting to us as part of the investigation.
02My host says the problem is the website, while my developer says it is the server. Who is right?
That is the most common reason people come to us, and the honest answer is that it is often neither party's fault alone. A PHP memory limit, an inode cap on a shared plan, or a slow query can each produce a symptom that looks like the other side's problem. We look at both and tell you which it is, with the log lines to back it up — you can forward that to whichever party needs to act.
03Can you pay attention to the busy hours instead of just fixing and leaving?
Yes. If a site only breaks under load, a quiet-hour test proves little. We identify when traffic actually peaks and compare logs and resources in that state instead of declaring success when demand is low.
04How much access do you need, and is it safe to give it?
As little as the task needs. Read-only access is often enough for the investigation, and root is only requested when the repair genuinely requires it. Use temporary credentials, and remove them when we are done — we will remind you to. We work through your own host's control panel where that is sufficient.
05Will you change things on my live server without telling me?
No. Investigation and repair are separate steps. You get the findings and the proposed change before anything is altered, and if we discover the fix is larger than expected we come back to you rather than continuing and billing for it.
06My site goes down every time traffic spikes. Can that be fixed?
Usually, once we know which resource runs out first. PHP-FPM workers, database connections, memory and storage I/O produce different symptoms and require different fixes. We identify the limit and explain whether configuration or additional capacity is justified.
07Do you handle emergencies?
Yes. Send the ticket with the word urgent, the affected URL, and what you were doing when it broke. For a site that is fully down we prioritise restoring service first and finding the root cause second, and we tell you which of the two we are doing at any point.
08Can I get the problem diagnosed before committing to the repair?
Yes, and for anything non-trivial we prefer it that way. You get the cause and a quote, and you decide whether we do the work, your own developer does it, or you leave it. The diagnosis is yours either way.
09Do you offer ongoing management rather than one-off fixes?
Yes. A monthly plan can cover an agreed mix of patching, monitoring, backup verification and support work. The systems, response expectations, exclusions and commercial terms are scoped against what you actually run.
10What should I put in the first message?
The domain, what is broken, when it started, what changed just before, and any error text exactly as it appears. Do not send passwords in that first message — we will tell you what access is needed and how to share it once we have read the symptoms.
Tell us the symptoms
Server problem and no sysadmin on the team?
Tell us what is happening. You do not need to know the technical cause, and there is no obligation to authorise changes before you understand the proposed work.