Why is my site slow?

Diagnose it on TurboStack

Start by confirming where the time goes - do not change config without measuring.

1. Open the host's Health tab and read the **Host Monitoring**
   cards: **CPU**, **RAM**, **Memory swap**, and **Disk**. Use the 1H/8H/1D/7D range buttons to
   see whether the pressure is constant or spikes. Sustained high CPU, RAM near full, or any
   active swapping all point to a resource bottleneck.
2. Check **Top Issues** on the same tab - TurboStack ranks the most important PERFORMANCE and
   STABILITY problems it has detected and suggests a fix.
3. Look at the **Services** checks (database, cache, web server) and the database/cache hit-ratio
   metrics. A low cache hit ratio means requests are missing the cache and hitting PHP or the
   database directly.
4. Use the fleet Monitoring dashboard to see trends across hosts and
   any open alerts.
5. Check **History** (Revisions / Deploys) to see whether a recent publish or deploy coincides with
   the slowdown. If so, that change is the most likely cause and you can roll back.

> [!TIP]
> Swap activity on the Health tab is the clearest sign of memory pressure. When a host is swapping,
> everything slows down - treat it as a memory problem first (see
> Out of memory).


Why is my site slow?

Cold or missing caches

site slow application slow magento slow improve performance slow page load cache hit ratio Blackfire bot traffic

After a deploy, a content change, or a cache flush, the caches are empty and every request does
full work until they warm up. A persistently low hit ratio (rather than a brief dip) points to a
caching layer that is being bypassed or invalidated too often.

TurboStack provides several caching layers - Redis object cache, Varnish full-page cache, and PHP
OPcache. The fastest safe fix is usually to let the cache warm, and to clear only the layer that is
serving stale or broken content. Connect over SSH and use `tscli`:

```bash
tscli varnish clear    # purge stale full-page cache
tscli opcache clear    # force PHP to recompile after a code change
```

- See Clear the Redis cache,
  Clear the Varnish cache, and
  Flush the PHP OPcache for what each command does and what
  to expect.
- See Performance tuning for how the layers fit together and
  how to size them.

> [!NOTE]
> `tscli redis clear` flushes the **cache instance (6379)** - all of its databases - while leaving
> the **persistent instance (6378)** with sessions and queues intact. Expect a temporary slowdown
> while the cache rebuilds.

After clearing, expect the first requests to be slower while the caches refill. Warm critical pages
by visiting them (or let your sitemap/crawler do it) before judging the result.


Why is my site slow?

Slow database queries

A single slow or unindexed query can drag down an otherwise healthy site, especially in the admin
or at checkout. If the database service check shows high load or long query times while CPU and RAM
look fine elsewhere, the database is the bottleneck.

See Database connection and performance problems for how to spot slow
queries, read the database logs, and size the buffer pool.


Why is my site slow?

Slow PHP application code

When caches are warm and the database is healthy but pages are still slow, the time is being spent
in PHP itself. Use the Blackfire profiler to find the exact functions and calls that are slow.
Enable it temporarily over SSH, profile the slow request, then disable it again:

```bash
tscli blackfire enable
# ... reproduce and profile the slow page ...
tscli blackfire disable
```

> [!NOTE]
> `tscli blackfire enable` and `disable` restart PHP-FPM, which briefly interrupts PHP processing.
> Enable the profiler only while you are actively investigating, and disable it afterwards.


Why is my site slow?

Bot and crawler traffic

A surge of automated traffic - aggressive crawlers, scrapers, or a small attack - can saturate PHP
and the database even when nothing else changed. On the Health graphs this shows up as a traffic
spike that tracks the slowdown.

TurboShield watches request rates and throttles abusive clients automatically. Clients that exceed
the limit receive a soft `429` response - a brief slowdown, not a firewall ban.
Raising the protection level (`low` / `medium` / `high` / `attack`) tightens the limits during an
event. See What is TurboShield?.

For a single clearly abusive address you can also block it directly:

```bash
tscli firewall check 203.0.113.10
tscli firewall block 203.0.113.10
```


Why is my site slow?

Undersized or saturated resources

If CPU is pinned, RAM is full, or the host is swapping under normal traffic - with warm caches and
no runaway query - the server has insufficient capacity for the current load. See
High CPU and load and Out of memory to confirm.


Why is my site slow?

When to optimize vs. scale

Optimize first, scale second:

- **Optimize** when the bottleneck is one layer: a cold or bypassed cache, a slow query, or
  inefficient PHP. Fixing the root cause is cheaper and faster than adding hardware.
- **Scale** (or raise an auto-tuned sizing key with evidence) only when the host is consistently
  resource-bound under legitimate traffic *after* caches are warm and code and queries are tuned.
  Adding capacity to mask an unindexed query or a misconfigured cache just postpones the problem.

The sizing keys (`mysql_innodb_size`, `redis_memory`, `varnish_cache_size`, and others) are
auto-tuned to the server. Override them only with measured evidence - see
Performance tuning.


Why is my site slow?

Prevent it

- Keep caching enabled and warm; clear caches surgically, not reflexively.
- Set a `monitoring_url` on every production application so you are alerted to slowdowns early
  (see Monitoring).
- Profile heavy pages with Blackfire before they become a problem.
- Let TurboShield manage traffic rather than chasing individual bots.
- Make permanent config changes in the TurboStack Platform and a publish - `tscli` acts on the running
  server now but does not change saved config.


Why is my site slow?

When to contact support

If the host stays slow after you have warmed the caches, ruled out the database, and confirmed it
is not traffic - or if a managed layer looks misconfigured - open a ticket at
Support. Include the host and domain, what changed (and when), the Health
graphs or Top Issues you are seeing, and any relevant log output.


Why is my site slow?

Related

- Performance tuning
- Database connection and performance problems
- High CPU and load
- Out of memory
- TurboStack CLI
- What is TurboShield?
- Health


TLS certificate problems

tls certificate error ssl not working certificate not renewing https not secure lets encrypt failed mixed content certificate expired

# TLS certificate problems

TurboStack issues and renews Let's Encrypt certificates automatically, so most HTTPS
problems are caused by Domain Name System (DNS) issues or by how the site links to its own resources. This page covers the common
cases - a certificate that never issues, a renewal that fails, and browser warnings - and how to
fix each one safely.

> [!NOTE]
> With `cert_type: letsencrypt`, issuance and renewal are **fully managed**. TurboStack requests
> the certificate during publishing and renews it well before expiry - you do not run any
> certificate commands yourself.


TLS certificate problems

Symptoms

- The site loads over `http://` but `https://` fails to connect or shows no certificate.
- The browser shows a padlock warning, "Not secure", or "Your connection is not private".
- A previously working certificate has expired or stopped renewing.
- The page is HTTPS but elements (images, scripts) fail to load with mixed-content warnings.


TLS certificate problems

Diagnose it on TurboStack

1. **Check the certificate status.** Open the host's **Applications** tab and review the application's
   **Hostnames** / Transport Layer Security (TLS) settings - confirm `cert_type` is `letsencrypt` and that every hostname the
   site answers to is listed in `server_name`. See
   TLS certificates.
2. **Check DNS.** A certificate cannot be issued until the domain resolves to the host. Confirm the
   A/AAAA records point at the server's public IPs - see
   Connecting your domain.
3. **Check what the browser reports.** Click the padlock to see the certificate's domains and expiry
   date. The error message usually names the exact problem (wrong domain, expired, self-signed).
4. **Check recent changes.** If HTTPS broke after a change, review the host's **History** to see
   whether a recent publish changed `server_name`, `cert_type`, or `cert_challenge`.

> [!TIP]
> To check the certificate and its chain from outside the server, test the site with an external
> tool such as the SSL Labs Server Test or the
> GlobalSign SSL Check. They report the certificate's validity,
> the full chain, and the expiry date as a visitor's browser sees them.


TLS certificate problems

Certificate not issued - DNS isn't pointing at the host yet

This is the most common cause. With the default **HTTP challenge**, Let's Encrypt validates
ownership by connecting to your domain over HTTP and expecting to reach this server. If the domain
doesn't resolve to the host - or still points at an old server - validation fails and no certificate
is issued.

**Fix:**

1. Point the domain at the host's public IPv4 (and IPv6) addresses, then wait for DNS to propagate  -
   see Connecting your domain.
2. Make sure every name in `server_name` resolves to the host, including `www`.
3. Publish again so TurboStack re-requests the certificate.

> [!TIP]
> For a domain that isn't pointed at the server yet, or for a **wildcard** (`*.example.com`)
> certificate, use the **DNS challenge** instead - see
> TLS certificates.


TLS certificate problems

Renewal failed

Renewal is automatic, but it can still fail if the conditions that allowed issuance have since
changed. Common examples: DNS was repointed elsewhere, a hostname was added to `server_name` that
does not resolve, or a redirect now blocks the Let's Encrypt validation path.

**Fix:**

1. Confirm DNS for every hostname still points at this host.
2. Make sure plain HTTP on the validation path is reachable. A blanket force-HTTPS redirect is fine
   on TurboStack, because the platform handles the ACME challenge. However, a custom redirect or
   rule that returns errors for all HTTP requests can block validation.
3. Re-trigger by publishing the host; TurboStack will attempt
   issuance again.

If renewal keeps failing after DNS and reachability are confirmed, contact support.


TLS certificate problems

Browser warning: wrong or missing domain

If you reach the site by a hostname that is not listed on the certificate, the browser reports a
name mismatch. This happens with a bare subdomain, or `www` when only the apex domain was added.

**Fix:** add every hostname the site serves to `server_name` (space-separated) so they're all
covered by one certificate, then publish. See
TLS certificates.


TLS certificate problems

Browser warning: certificate expired

A managed Let's Encrypt certificate should never expire on its own. If a browser reports an expired
certificate, it usually means renewal has been failing for some time (see **Renewal failed** above)
or the browser cached an old certificate. Reload after fixing renewal; if it persists, publish to
force a fresh issuance.


TLS certificate problems

Browser warning: not trusted / self-signed

A "not trusted" warning where you expected a public certificate usually means the application is still
set to `cert_type: selfsigned` (intended for internal or test sites). Switch it to `letsencrypt`
and publish - see TLS certificates.


TLS certificate problems

Mixed content - padlock shows a warning

The page itself is served over HTTPS, but it links to some resources (images, CSS, scripts) using
hard-coded `http://` URLs. Browsers block or flag this insecure content.

**Fix:** update the application so it generates HTTPS (or protocol-relative) URLs. In most CMS and
e-commerce apps this means setting the site's base/secure URL to `https://`. Use the browser's
developer console to find which resources are still requested over HTTP.


TLS certificate problems

HTTPS works but HTTP isn't redirected

If both `http://` and `https://` serve the site, force all traffic onto HTTPS so visitors always get
the secure version - see How to force HTTPS. On TurboStack
this is the recommended setup; the platform still allows Let's Encrypt's validation requests through.


TLS certificate problems

Prevent it

- Point DNS at the host **before** requesting a certificate, and keep records current when you
  migrate (Connecting your domain).
- Keep `cert_type: letsencrypt` and list every hostname in `server_name`.
- Force HTTPS site-wide and fix mixed content at the source
  (Force HTTPS).
- Follow the Security hardening checklist for TLS best
  practices.


TLS certificate problems

When to contact support

If DNS resolves correctly, the HTTP validation path is reachable, and a certificate still won't
issue or renew, contact support. Include the **host**, the affected
**domain(s)**, the exact browser error, and what changed recently (DNS move, new hostname, redirect
rule).


TLS certificate problems

Related

- TLS certificates - certificate types and where to check status.
- Connecting your domain - DNS prerequisites for issuance.
- How to force HTTPS - redirect HTTP to HTTPS correctly.
- Security hardening checklist.
- Publishing - re-trigger issuance.
- Troubleshooting overview.


Access control and encryption

ssh access key based authentication tls encryption https secure access

# Access control and encryption

Access to your host is controlled with keys and permissions, and traffic to your applications is
encrypted in transit.


Access control and encryption

Key-based access

Server access uses **public-key SSH authentication**. You can disable password authentication and run
SSH on a custom port. Manage keys per person (and at group level) so you can grant and revoke access
cleanly. See SSH access.


Access control and encryption

Encryption in transit

Applications are served over **HTTPS** with free Let's Encrypt certificates that renew automatically, so
data between your visitors and the server is encrypted. See
TLS certificates.


Access control and encryption

Controlling who can do what

- Give people their own Customer Center access through
  contacts and teams, with only the permissions
  they need.
- Protect your account with two-factor authentication.
- On the TurboStack Platform, access is scoped to your account, and a single login can manage several accounts.

> [!NOTE]
> For details on encryption at rest for your specific plan, contact support.


Access control and encryption

Related

- SSH access
- TLS certificates
- Two-factor authentication
- Security hardening


Backups and recovery

backups restore backup disaster recovery data recovery off-site backup retention

# Backups and recovery

Hosted Power takes managed backups of your environment as part of the Service Level Agreement (SLA),
so you can recover after a mistake, a bad deploy, or an incident.


Backups and recovery

Automatic backups

- Backups run **daily** and are kept for **20 days**. This applies to every TurboStack environment,
  whichever SLA tier you are on. Need a longer retention or extra snapshots? Ask
  Support.
- They cover your environment - the application files and databases on the host.
- Because the platform backs up daily for you, running your own daily backup on the host is usually
  redundant and just consumes disk - see Disk full.


Backups and recovery

Restoring data

You restore from the host's Backups tab - browse the backup jobs,
open a backup's contents, and restore files or a database (restore to staging first to verify, when
you can).

> [!NOTE]
> Restores are included in the price and service. The time needed to perform a restore falls outside
> the SLA response window. For a large or urgent recovery, contact support.


Backups and recovery

Related

- Backups (Hosts tab)
- How we protect your platform
- Support


DDoS and abuse protection

ddos protection abuse protection bot mitigation rate limiting turboshield

# DDoS and abuse protection

A Distributed Denial-of-Service (DDoS) attack floods your environment with traffic so that real
visitors can no longer reach it. Hosted Power mitigates this at the network and application level.


DDoS and abuse protection

How attacks are mitigated

- **Rate limiting.** TurboShield caps abusive request rates per IP and returns a soft HTTP 429 instead
  of serving the flood. It also caps how many concurrent connections a single IP may hold. That cap
  scales with the TurboShield level (from 160 connections at the lowest level down to 60 in attack
  mode) and is kept deliberately high so legitimate HTTP/2 and HTTP/3 clients, which open many parallel
  streams, are not blocked by mistake. See TurboShield.
- **High availability.** The platform runs active/passive VIP failover with keepalived: if the active
  node fails under load, the virtual IP moves to a standby node so the service stays reachable. This is
  failover for resilience, not an application-layer traffic filter.
- **Blackhole routing.** Attack traffic can be routed into a "black hole" and discarded before it
  reaches the host.
- **Reputation-based blocking.** The firewall bans known-bad
  and repeat-offender IPs automatically.

For very large attacks, a third-party DDoS-protection service (such as Cloudflare) can be added in
front for extra capacity.


DDoS and abuse protection

What to do during an attack

1. Raise the host's TurboShield level to **attack** while the incident lasts, then return it to
   **medium** afterwards - see Configure TurboShield.
2. Block or allow specific IPs from the TurboStack CLI (`tscli firewall block`,
   `tscli firewall whitelist`).
3. If the attack overwhelms the host, contact support - the on-call team
   can mitigate at the network level and escalate to the cloud provider if needed.


DDoS and abuse protection

Related

- How we protect your platform
- TurboShield
- Firewall
- TurboStack CLI


How we protect your platform

platform security server hardening automatic updates turboshield turboradar malware scanning

# How we protect your platform

Every TurboStack host runs several security layers that Hosted Power manages for you. You do not
configure these - they are on by default and kept up to date centrally.


How we protect your platform

Hardened base with automatic updates

Hosts run a hardened operating system, and security updates are applied automatically. The platform
checks for updates several times a day and patches centrally, so known vulnerabilities are closed
quickly without action from you.


How we protect your platform

Firewall

A firewall runs on every host and reacts to abuse within seconds. It watches failed logins across
services (SSH, FTP, mail and HTTP) and bans repeat offenders automatically. See
Firewall.


How we protect your platform

TurboShield

TurboShield rate-limits traffic per visitor and classifies bots, throttling abusive request rates
before they overload the host. A throttled client receives a soft HTTP 429 response rather than a
hard ban. See TurboShield and
DDoS and abuse protection.


How we protect your platform

TurboRadar and malware protection

TurboRadar provides runtime threat detection and scans for commerce malware, watching for suspicious
process behavior and known-bad files after your application is deployed. It **detects and reports** -
findings surface in the host's Threat Center. Actively blocking
malicious requests - injection attempts, distributed brute-force attacks and known exploits - is done
by the Web Application Firewall (WAF), TurboShield and the Firewall.


How we protect your platform

Encryption, backups and traffic protection

- **Free SSL/TLS** (Secure Sockets Layer / Transport Layer Security) for your applications - see Access control and encryption.
- **Managed daily backups** - see Backups and recovery.
- **Network-level Distributed Denial-of-Service (DDoS) mitigation** - see DDoS and abuse protection.


How we protect your platform

Related

- Threat Center
- Security overview
- Security hardening (your part)


Trust and security

turbostack security hosted power security is turbostack secure managed hosting security

# Trust and security

TurboStack is a **fully managed** platform: Hosted Power secures, patches and maintains the underlying
servers so you can focus on your application. This section explains what is handled for you, and where
your own responsibility begins.


Trust and security

What "managed and secured" means

On every host, the platform provides:

- A hardened operating system with **automatic security updates**.
- A **firewall** on every host and **TurboShield** rate limiting and bot control.
- **TurboRadar** runtime threat detection and malware scanning.
- **Malware protection** and a **Web Application Firewall (WAF)**.
- Free **SSL/TLS** (Secure Sockets Layer / Transport Layer Security) encryption and **managed daily backups**.
- Network-level **Distributed Denial-of-Service (DDoS)** mitigation.

See How we protect your platform for the detail.


Trust and security

Shared responsibility

Security is shared between Hosted Power and you:

| Hosted Power handles | You handle |
|---|---|
| Server hardening, OS and platform patching | Keeping your application, plugins and themes up to date |
| Firewall, TurboShield, TurboRadar, WAF, DDoS mitigation | Strong passwords, who you grant access to, and your own data |
| Managed backups and the network | App-level configuration and which services you expose |

Your part is covered in the Security hardening checklist.


Trust and security

In this section

- How we protect your platform
- DDoS and abuse protection
- Backups and recovery
- Access control and encryption
- Reporting a security issue


Trust and security

Related

- Security overview
- Security hardening (your part)
- Support


Reporting a security issue

report vulnerability responsible disclosure security contact security issue

# Reporting a security issue

If you discover a security vulnerability in TurboStack or your hosted environment, please report it to
us so we can fix it. We appreciate responsible disclosure.


Reporting a security issue

How to report

Email **support@hosted-power.com** with the details. Include:

- What you found and the **potential impact**.
- The **affected host, domain or URL**.
- Clear **steps to reproduce** it.
- How we can **reach you** for follow-up.

We will acknowledge your report and work with you on a fix.


Reporting a security issue

Please do

- Report the issue privately and give us reasonable time to resolve it before disclosing it.
- Only test against your own environment.


Reporting a security issue

Please do not

- Access, modify or delete data that is not yours.
- Run disruptive tests (for example denial-of-service) or anything that degrades the service for
  others.


Reporting a security issue

Related

- How we protect your platform
- Support