Uptime statistics report

The State of Uptime 2026

How websites, APIs, cron jobs and the services behind them actually stayed online over the last 12 months, measured by Pulsetic’s monitoring network. Aggregated, anonymized and free to cite.

Sep 2025 to Sep 2026 · Checks from 15 locations · Refreshed 24 Sep 2026

  • 98.59%

    average uptime across every monitored endpoint

  • 53.4%

    of monitors had at least one confirmed outage

  • 46%

    of outages were over in under 5 min

  • 90.1%

    of outages were resolved within an hour

How much of the time websites are up

The average monitored endpoint was up 98.59% of the time. 57% of monitors round to 100% uptime, while 6.4% were up less than 95% of the time and carry much of the downtime.

  • 49

    confirmed outages per affected monitor, on average

  • 57%

    of monitors round to 100% uptime

  • 6.4%

    of monitors were up less than 95% of the time

  • Uptime, distributed

    Share of monitors in each uptime band

    100%57%
    99.9–100%8.7%
    99.5–99.9%15%
    99–99.5%5.3%
    95–99%7%
    < 95%6.4%
  • Uptime by check type

    Average uptime. Bar length shows the share of time spent down.

    TCP port99.08% up
    Ping (ICMP)98.51% up
    HTTP(S)97.44% up

    HTTP(S) monitors spent 2.8× as much time down as TCP port monitors. Ping and TCP checks only test that a host answers; an HTTP check also depends on the application, TLS and the origin.

How long outages last, and when they start

46% of confirmed outages were over in under 5 min, and 90% within an hour. The 9.9% that ran longer are the long tail: they pull the average recovery time up to 4.7 h and do most of the damage.

  • 4.7 h

    average time from first failure to recovery

  • 9.9%

    of outages lasted longer than an hour

  • 25%

    of outages began on a Saturday or Sunday

  • How long outages last

    Confirmed outages by duration

    Under 5 min46%
    5–30 min37%
    30 min–1 h7.3%
    1–6 h7.6%
    Over 6 h2.3%
  • When outages start

    Confirmed outage starts by hour of day (UTC). Busiest hour in red.

    The busiest hour is 15:00 UTC. 23% of outages start between 00:00 and 06:00 UTC.

Outage starts by weekday and hour

The same outages as above, split by day of the week (UTC). Darker means more.

Based on 2,201,561 confirmed outages. Timestamps are aggregated in UTC; a view in each monitor’s local time is planned once monitors carry a time zone.

Response time around the world

Pulsetic runs checks from 15 locations worldwide, so the same websites can be timed from different parts of the world. The average HTTP check took 699 ms from start to finish, and the biggest share of it was server wait (TTFB).

  • 699 ms

    average response time, across every HTTP check

  • 509 ms

    average from Europe, the fastest region

  • 1,117 ms

    average from Africa, the slowest region

Where the time goes

The average HTTP check, split into its phases

  • 46 ms

    DNS lookup

  • 54 ms

    TCP connect

  • 73 ms

    TLS handshake

  • 395 ms

    Server wait (TTFB)

  • 130 ms

    Content transfer

Server wait (TTFB) is 57% of the average request. Most uptime reports stop at the total; Pulsetic records each phase on every check.

By region

Average response time and uptime, measured from each region

RegionAvg responseCompared with the slowestUptime
Europe 509 ms
98.81%
North America 534 ms
98.98%
South America 913 ms
97.87%
Asia/Australia 1,088 ms
97.82%
Africa 1,117 ms
98.72%

Response time mostly reflects the distance between each region and the websites being checked, not the quality of the region itself.

What real visitors experience

Synthetic checks say a website is up. Real User Monitoring says how it felt, using Core Web Vitals from actual page views. Mobile trails desktop most on INP (responsiveness): 70% of mobile page views rate Good, against 82% on desktop. On the other vitals the two are within 3 points.

  • Page views rated Good

    Share of real page views meeting Google’s Good threshold, desktop and mobile

    LCP loading

    Desktop66%
    Mobile65%

    INP responsiveness

    Desktop82%
    Mobile70%

    CLS visual stability

    Desktop81%
    Mobile83%
  • 75th percentile, by device

    Three in four page views were at least this good

    VitalDesktopMobileMobile vs desktop
    LCP 2.46 s 2.45 s 0%
    INP 106 ms 200 ms +89%
    CLS 0.06 0.09 +49%

    LCP is Largest Contentful Paint, INP is Interaction to Next Paint and CLS is Cumulative Layout Shift. Lower is better for all three.

The errors that never reach your server logs

RUM also records the JavaScript exceptions and failed network requests that real visitors hit in the browser, which the server never sees.

  • 274.1

    errors per 1,000 page views, JavaScript and failed requests together

  • 59%

    of errors were failed network requests; 41% were JavaScript exceptions

  • 1.5×

    as many errors per page view on mobile as on desktop

  • Failed requests by status

    Share of failed network requests by HTTP status

    No response (blocked, cancelled or offline)89%
    422 Unprocessable Content3%

    “No response” means the browser never got an HTTP status back: the request was blocked by an extension or CORS, cancelled by navigation, or the visitor was offline. Linked codes open a guide to the error.

  • Errors by browser

    Share of all client-side errors

    Chrome62%
    Safari21%
    Firefox6.7%
    Edge5.9%
    Samsung Internet1.2%
    Opera0.7%
    Yandex Browser0.1%
    Other3%

    Largely a mirror of browser market share. Bots, in-app browsers and unrecognized user agents are counted under Other.

Based on 2,249,100 real-user page views.

Cron jobs and scheduled tasks

Heartbeat monitoring expects a ping from a background job on a schedule. When the ping is late by more than its grace period, the job counts as missed. The most common interval is 1–5 min, used by 54% of jobs.

  • 1.2 h

    average grace period before a late job counts as missed

  • 13.8 h

    average time a missed job stayed missed

  • 3,347

    cron job monitors in the sample

  • How often jobs run

    Share of heartbeat monitors by schedule interval

    1 min or less15%
    1–5 min54%
    5–15 min9.1%
    15 min–1 h8.1%
    Over 1 h14%
  • How long a missed job stays missed

    Missed runs by time until the job checked in again

    Under 5 min45%
    5–30 min26%
    30 min–1 h8.3%
    1–6 h9.2%
    Over 6 h12%

Domains: who registers them, and when they lapse

Domain monitoring reads registry data for every watched domain: expiry date, registrar, transfer lock and age. Pooled together, it shows how the domain layer is actually run.

  • 2.4%

    of domains expire within the next 30 days

  • 8.2 yrs

    average age of a monitored domain

  • 46%

    end in .com, still the default

  • 68%

    have a registrar transfer lock

  • Most common endings

    Share of monitored domains by top-level domain

    .com46%
    .org4.2%
    .de3.5%
    .net3.2%
    .com.au2.1%
    .co.uk2%
    .io1.8%
    .dev1.8%
    .cz1.6%
    .ch1.3%
  • Registrars

    Share of monitored domains by registrar

    RegistrarShare
    GoDaddy.com 16%
    NameCheap 9.3%
    Cloudflare 9.2%
    Spaceship 4%
    Tucows Domains 2.8%
    Global Domains International 2.7%
    Porkbun 2.5%
    Amazon Registrar 2.3%
    Netregistry Wholesale 1.9%
    HOSTINGER operations 1.9%

Registry data came from RDAP for 86% of domains and from WHOIS for 11%. Based on 2,214 monitored domains.

SSL certificates: what signs them, and what lapses

These are the certificates SSL monitoring watches, split by signature algorithm and time to expiry. ECDSA now signs 48% of them. Effectively none, under 0.01%, are still signed with SHA-1 or MD5. This covers the certificate itself, not the TLS version a connection negotiates.

  • 1.1%

    of certificates expire within the next 14 days

  • 0.1%

    were already expired or invalid

  • 51%

    are signed with RSA with SHA-256, the most common algorithm

Signature algorithms

Share of monitored certificates

RSA with SHA-25651%
ECDSA with SHA-25633%
ECDSA with SHA-38415%
RSA with SHA-3840.8%

Based on 74,448 monitored certificates.

The services you depend on

Pulsetic follows the public status pages of 4,379 services, from payment processors to hosting, and records every incident they report. This is third-party reliability as the providers describe it themselves, and it is what dependency monitoring alerts you about.

  • 63,578

    incidents reported by tracked services

  • 2.1 h

    median time for a service to resolve an incident

  • 35%

    were rated major or critical by the provider

  • 1.4%

    were planned maintenance rather than outages

  • Incidents by category

    The eight categories that reported the most incidents

    Payment Processing5,251
    Financial Services3,207
    Security Operations3,028
    Education Technology2,544
    AI & ML Platforms2,539
    E-Commerce2,362
    VoIP & Communication2,341
    Cloud Platforms2,114

    The other 144 categories reported 40,192 incidents between them.

  • Which status page platform they use

    Share of tracked services by status page platform

    Atlassian Statuspage87%
    Instatus5.4%
    Better Stack5.2%
    incident.io1.6%
    OpenStatus0.2%
    Their own or another platform0.2%

Impact and timing are each provider’s own classification, taken from its status page. Separately, 35% of the outage reports visitors submit on Pulsetic’s public status pages came from Europe.

What each number of nines allows

An uptime target converted into the downtime it permits. For any other target, use the uptime SLA calculator.

Uptime targetDowntime a yearA monthA weekIn practice
99% 3d 15h 36m 7h 18m 1h 41m "Two nines". More than three and a half days of downtime a year.
99.9% 8h 46m 43m 50s 10m 5s The common baseline for paid SaaS.
99.95% 4h 23m 21m 55s 5m 2s A typical premium tier.
99.99% 52m 36s 4m 23s 1m 0s "Four nines". Takes serious engineering investment.
99.999% 5m 15s 26s 6s "Five nines". Close to the limit of what is achievable.

How these numbers are made

    1. Real checks, not a survey

      Every figure comes from production monitoring: HTTP, TCP, ping, heartbeat, SSL and domain checks, pooled across the whole network.

    2. Confirmed from another location

      A monitor only counts as down once a second location confirms the failure, so a blip seen from one location never lowers the uptime figure.

    3. Blips excluded

      An outage runs from the first failed check to the first successful one. Sub-minute flaps that recover on their own are filtered out.

    4. Timestamps in UTC

      Hour-of-day and day-of-week patterns are aggregated in UTC. Response time is the full request, averaged across HTTP checks.

    5. Aggregated and anonymized

      Nothing here identifies a customer, a domain or an individual website. Each section states its own sample size.

  • What this edition covers

    • WindowSep 2025 to Sep 2026
    • Confirmed outages2,201,561
    • Real-user page views2,249,100
    • SSL certificates74,448
    • Domains2,214
    • Cron job monitors3,347
    • Third-party status incidents63,578

    Cite this report

    “The State of Uptime 2026”, Pulsetic, pulsetic.com/uptime-statistics/, figures as of 24 September 2026.

Frequently asked questions

  • Can I cite this report?

    Yes. You are free to cite and quote any figure with attribution to Pulsetic and a link back to this page.

  • How is uptime calculated?

    Uptime % = (available time ÷ total monitored time) × 100. It is worked out for each monitor from its own checks, with failures confirmed from a second location, and then averaged across monitors.

  • What counts as an "outage"?

    A run of consecutive failed checks, confirmed by a second location, lasting at least the alert threshold. It ends at the first check that succeeds again.

  • What's the sample and window?

    This edition covers the 12 months from September 2025 to September 2026: 2,201,561 confirmed outages, 2,249,100 real-user page views, 74,448 SSL certificates, 2,214 domains, 3,347 cron job monitors and 63,578 third-party status incidents.

  • Where does the real-user data come from?

    From Pulsetic's cookieless Real User Monitoring, which collects anonymized Core Web Vitals, navigation timings and browser errors from real page views on websites that have it installed.

  • How often are the numbers updated?

    The figures are recalculated from live monitoring data over a rolling 12-month window and refreshed on this page every 15 minutes. If you cite a figure, note the date you read it.