Website down checker / siteground.com
Is siteground.com down right now?
No, siteground.com is up.
- Status
- Up
- Reachable from
- 16 of 16 locations
- Typical response
- 214 ms Good
- Slowest location
- London · 512 ms Good
- Last checked
Probes this hostname from 16 locations. The live link always shows the latest check; a check link stays as it is for 90 days.
QuickStatus is not affiliated with SiteGround.
How fast it feels to visitors
Good in all 16 locations. Visitors won't notice a server delay.
The server sends its first byte in 69 ms (Ashburn) to 512 ms (London). Up to 800 ms, the server isn't what makes the page feel slow. Above that, visitors look at a blank screen long enough to notice.
What this suggests: Fastest from Ashburn and slower with distance (London: 512 ms). The page looks like it's served from one region near Ashburn. Caching the page at a CDN, or serving it from a region closer to Europe, would cut that wait.
Fastunder 200 ms
8 locations
Feels instant. The server adds no wait a visitor would notice.
Good200–800 ms
8 locations
Within Google's good range. Most of the wait is the page loading, not the server.
Noticeable0.8–1.8 s
0 locations
Visitors notice a blank wait before anything appears. Google rates this as needing improvement.
Slowover 1.8 s
0 locations
Google rates this poor. With loading on top, the page misses the 2.5 s target for showing its main content.
Response time by location
Americas
- Ashburn us-east-169 msFast403 Forbidden · blocks cloud probes
- Columbus us-east-2117 msFast403 Forbidden · blocks cloud probes
- San Francisco us-west-1173 msFast403 Forbidden · blocks cloud probes
- Portland us-west-2107 msFast403 Forbidden · blocks cloud probes
- Montreal ca-central-1148 msFast403 Forbidden · blocks cloud probes
- São Paulo sa-east-1215 msGood403 Forbidden · blocks cloud probes
Europe
- Dublin eu-west-1171 msFast403 Forbidden · blocks cloud probes
- London eu-west-2512 msGood403 Forbidden · blocks cloud probes
- Paris eu-west-3198 msFast403 Forbidden · blocks cloud probes
- Frankfurt eu-central-1192 msFast403 Forbidden · blocks cloud probes
- Stockholm eu-north-1218 msGood403 Forbidden · blocks cloud probes
Asia Pacific
- Tokyo ap-northeast-1217 msGood403 Forbidden · blocks cloud probes
- Seoul ap-northeast-2290 msGood403 Forbidden · blocks cloud probes
- Osaka ap-northeast-3214 msGood403 Forbidden · blocks cloud probes
- Singapore ap-southeast-1279 msGood403 Forbidden · blocks cloud probes
Oceania
- Sydney ap-southeast-2256 msGood403 Forbidden · blocks cloud probes
Ashburn, Columbus, San Francisco and 13 more answered with HTTP 403. The server responded, so it's up, but a firewall or bot check is refusing cloud traffic. Your browser may still get through.
Time from connecting to the first response byte (TCP, TLS and server time, DNS excluded) on a fresh connection from a cloud data center. Visitors on home or mobile networks wait longer. Thresholds follow Google's TTFB guidance (good up to 0.8 s, poor above 1.8 s).
How to read this check
- When do visitors start noticing a slow site?
- The number per location is how long the server takes to send its first byte. Up to about 800 ms, the server isn't what makes a page feel slow. Past 800 ms, visitors look at a blank screen long enough to notice. Past 1.8 s, Google rates server response as poor, and with loading on top the page can't show its main content within Google's 2.5 s target.
- Fast in one place, slow everywhere else
- Response time grows with distance from the server. If one city is fast and the rest climb steadily, the page is served from a single region. A CDN that caches the page, or a second region, brings far-away visitors closer to the fast number.
- All 16 regions failing
- The hostname is failing from every probe location. That usually means the origin is down, the TLS certificate has expired, or authoritative DNS is not answering. It is not a problem on one network path.
- One region or continent failing
- When a single city or one continent is offline and the rest return HTTP 200, the origin is up. The failure is usually a CDN or anycast edge route, or a regional cloud impairment between that probe and the site.
- All 16 regions return 200, but it fails in your browser
- The site is reachable from our probes. A local failure is usually a stale ISP DNS cache, a corporate firewall or VPN, or a browser extension blocking the request.
- HTTP 403 or 429 from the probes
- A 403 or 429 from many cloud probes often means a WAF or Cloudflare bot challenge is blocking AWS IP ranges. That is not the same as an application outage. Compare the status code with what your browser receives.
Need to know when something goes down?
Monitor any endpoint on a schedule and get Slack, Discord, PagerDuty, or webhook alerts. Free checks run every 5 minutes. Pro can check every 60 seconds.