Can I cite this report?

Yes. The figures are published under the Creative Commons Attribution 4.0 license (CC BY 4.0): you may quote, republish and adapt them, commercially too, as long as you credit Pulsetic and link back to this page.

What is a good uptime percentage?

For a paid service, 99.9% (three nines) is the common baseline: about 8h 46m of downtime a year. 99.95% allows about 4h 23m and 99.99% about 52m 36s, which takes serious engineering investment. For comparison, the mean endpoint in this report was up 98.53%, about 5 days of downtime a year, and 72% of monitors reached 99.9% or better.

Which uptime metrics should I track?

Uptime percentage over a month and a year, the number of outages, and how long they take to fix: mean time to recovery, counted from when the failure begins, so detection time is included. Add response time, since a slow site can count as up, and the expiry dates of SSL certificates and domains, which take a site down on a known date. For scheduled jobs, track missed check-ins rather than uptime.

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?

The uptime and outage figures cover the 12 months from 1 October 2025 to 1 October 2026, a sample of 2,227,171 confirmed outages. The other sections have their own samples: 2,484,563 real-user page views, 74,609 SSL certificates, 2,261 domains, 3,554 cron job monitors and 65,123 third-party status incidents. Real-user data runs from June 2026, and browser errors from July 2026; visitor outage reports run from May 2026.

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?

Pulsetic recalculates the figures from live monitoring data once a month, on the 1st, over a rolling window, and this page checks for new figures every 15 minutes. The "Figures as of" date at the top of the page shows the latest recalculation; if you cite a figure, give that date.

Uptime statistics report

The State of Uptime 2026

Name: The State of Uptime 2026
Creator: Pulsetic
License: https://creativecommons.org/licenses/by/4.0/

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.

1 Oct 2025 to 1 Oct 2026 · Checks from 15 locations · Figures as of 1 Oct 2026, 04:37 UTC · Report revised 28 Sep 2026

Key findings
Uptime
Outages
Response time
Real users
Cron jobs
Domains
Certificates
Dependencies
SLA table
Methodology

98.53%

mean uptime across every monitored endpoint
53.6%

of monitors had at least one confirmed outage
46%

of outages were over in under 5 min
90.2%

of outages were resolved within an hour

Key findings

1 October 2025 to 1 October 2026, figures as of 1 October 2026, 04:37 UTC

Endpoints monitored by Pulsetic averaged 98.53% uptime (the mean across monitors) in the 12 months to 1 October 2026, about 5 days of downtime a year at that average, while more than half of monitors (65%) round to 100% uptime.
53.6% of the endpoints Pulsetic monitored had at least one confirmed outage in the 12 months to 1 October 2026.
Of the 2,227,171 outages Pulsetic confirmed in the 12 months to 1 October 2026, 46% were over in under 5 min and the median outage lasted 5–30 min; the mean was 4.5 h, pulled up by the 2.3% that ran over 6 h.
90.2% of the outages Pulsetic confirmed in the 12 months to 1 October 2026 were resolved within an hour.
The mean HTTP check Pulsetic ran in the 12 months to 1 October 2026 took 702 ms; by the region the check ran from, Europe was fastest at 509 ms and Africa slowest at 1,133 ms.
Pulsetic’s real-user monitoring, which has recorded browser errors since July 2026, logged about 115 JavaScript exceptions and 17 failed HTTP responses (status 400 or above) per 1,000 page views, figures as of 1 October 2026.
1.2% of the 74,609 SSL certificates Pulsetic monitors expire within 14 days of 1 October 2026, and 0.1% were already expired or invalid.
Across the 4,379 third-party services whose public status pages Pulsetic follows, providers reported 65,123 incidents, with a median of 2.1 h to resolve, figures as of 1 October 2026.

How much of the time websites are up

The mean monitored endpoint was up 98.53% of the time, about 5 days of downtime a year at that average. More than half of monitors (65%) round to 100% uptime, while 5.7% were up less than 95% of the time.

50
mean number of confirmed outages per affected monitor
65%
of monitors round to 100% uptime
5.7%
of monitors were up less than 95% of the time

Uptime, distributed

Share of monitors in each uptime band

Rounds to 100%: 65%

99.9–100%: 7.3%

99.5–99.9%: 12%

99–99.5%: 5.2%

95–99%: 4.9%

< 95%: 5.7%

A monitor can round to 100% and still have had a short confirmed outage.
Uptime by check type

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

TCP port: 98.82% up

Ping (ICMP): 98.73% up

HTTP(S): 97.56% up

HTTP(S) monitors spent 2.1× 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.2% within an hour. The median outage lasted 5–30 min. The mean time from first failure to recovery was 4.5 h, pulled up by the long tail: 9.8% of outages ran longer than an hour and 2.3% over 6 h. A monitor that had outages averaged 50 of them over the 12 months, so about 12 began on a Saturday or Sunday (UTC), when most teams are off.

5–30 min
median outage duration, the bucket that holds the middle outage
4.5 h
mean time from first failure to recovery
9.8%
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 min: 46%

5–30 min: 37%

30 min–1 h: 7.3%

1–6 h: 7.5%

Over 6 h: 2.3%

When outages start

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

Outage starts per hour ranged from 79,193 at 03:00 UTC to 105,176 at 15:00 UTC. 23% of outages started between 00:00 and 06:00 UTC.

Show the numbers

Hour (UTC)	Outage starts
00:00	93,286
01:00	85,872
02:00	86,201
03:00	79,193
04:00	85,035
05:00	86,210
06:00	91,882
07:00	101,002
08:00	96,589
09:00	95,902
10:00	100,744
11:00	94,576
12:00	103,051
13:00	104,540
14:00	104,794
15:00	105,176
16:00	97,629
17:00	91,909
18:00	90,528
19:00	88,282
20:00	86,504
21:00	87,154
22:00	85,157
23:00	85,955

Outage starts by weekday and hour

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

Mon Tue Wed Thu Fri Sat Sun

The busiest hour of the week was Tuesday 13:00 UTC, with 20,279 outage starts, and the quietest was Sunday 21:00 UTC, with 10,319.

Show the numbers

Hour (UTC)	Mon	Tue	Wed	Thu	Fri	Sat	Sun
00:00	13,536	12,872	13,085	14,870	13,891	12,430	12,602
01:00	11,710	12,326	12,720	13,448	12,255	11,442	11,971
02:00	11,376	12,468	12,417	13,339	12,861	11,333	12,407
03:00	10,893	11,529	11,887	12,435	11,425	10,352	10,672
04:00	11,577	11,880	13,095	12,757	12,601	11,483	11,642
05:00	11,667	12,460	13,856	12,885	12,844	10,663	11,835
06:00	13,196	13,664	13,919	13,415	14,122	11,421	12,145
07:00	16,026	15,428	15,025	15,536	15,751	11,923	11,313
08:00	14,903	15,331	14,931	13,998	14,532	11,172	11,722
09:00	15,333	14,919	14,521	14,197	14,283	11,582	11,067
10:00	14,725	14,773	16,019	14,190	17,569	11,554	11,914
11:00	13,768	17,447	14,369	13,869	13,837	10,807	10,479
12:00	13,988	19,970	15,124	16,730	14,069	11,947	11,223
13:00	14,871	20,279	16,296	16,559	14,481	11,580	10,474
14:00	16,569	16,427	15,764	16,730	14,887	12,548	11,869
15:00	15,655	16,720	16,645	16,699	14,808	12,251	12,398
16:00	15,575	16,036	15,248	14,979	13,631	11,310	10,850
17:00	13,558	14,241	14,976	13,988	12,860	11,443	10,843
18:00	13,254	14,449	15,249	13,623	12,148	11,007	10,798
19:00	12,644	13,270	15,588	12,313	11,923	11,358	11,186
20:00	12,566	13,700	14,304	12,856	11,518	11,112	10,448
21:00	11,978	13,945	15,275	12,708	10,872	12,057	10,319
22:00	12,572	12,791	13,757	12,642	11,500	11,218	10,677
23:00	12,010	12,303	12,721	12,511	11,209	11,427	13,774

Based on 2,227,171 confirmed outages from 1 October 2025 to 1 October 2026. 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 mean HTTP check took 702 ms from start to finish, and the biggest share of it was server wait.

702 ms
mean response time, across every HTTP check
509 ms
mean for checks run from Europe, the fastest region
1,133 ms
mean for checks run from Africa, the slowest region

Where the time goes

The mean HTTP check, split into its phases. Time to first byte is the sum of every phase before content transfer.

46 ms

DNS lookup
55 ms

TCP connect
74 ms

TLS handshake
400 ms

Server wait
125 ms

Content transfer

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

By region

Mean response time and uptime, by the region the checks ran from

Region	Mean response	Uptime
Europe	509 ms	98.69%
North America	566 ms	98.71%
South America	911 ms	97.87%
Asia/Australia	1,048 ms	98.17%
Africa	1,133 ms	98.56%

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.

LCP loading

Largest Contentful Paint: how soon the main content appears. Good is 2.5 s or less.

Page views rated Good

Desktop: 66%

Mobile: 64%
INP responsiveness

Interaction to Next Paint: how soon the page responds to a tap or click. Good is 200 ms or less.

Page views rated Good

Desktop: 82%

Mobile: 70%

75th percentile

Desktop: 112 ms

Mobile: (+86% vs desktop) 208 ms
CLS visual stability

Cumulative Layout Shift: how much the layout jumps while it loads. Good is 0.1 or less.

Page views rated Good

Desktop: 81%

Mobile: 83%

75th percentile

Desktop: 0.06

Mobile: (+57% vs desktop) 0.09

Good uses Google’s Core Web Vitals thresholds. The 75th percentile is the value three in four page views matched or beat; the chip compares mobile with desktop. Lower is better for all three. A 75th percentile that contradicts the share rated Good for the same vital and device is left out until the two agree.

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.

115
JavaScript exceptions per 1,000 page views
17
failed HTTP responses (status 400 or above) per 1,000 page views
142
requests per 1,000 page views that got no response (status 0), including requests the page cancelled itself
1.5×
as many errors per page view on mobile as on desktop

Worked out from 274.6 recorded errors per 1,000 page views, of which 42% were JavaScript exceptions and 58% failed network requests, split by the status shares below.

Failed requests by status

Share of failed network requests by HTTP status, among the ten most common statuses. Each code opens a guide to the error.

0 No response: 89%

400 Bad Request: 3.4%

422 Unprocessable Content: 3.1%

404 Not Found: 1.2%

403 Forbidden: 1.1%

502 Bad Gateway: 0.9%

429 Too Many Requests: 0.5%

500 Internal Server Error: 0.3%

401 Unauthorized: 0.2%

504 Gateway Timeout: 0.1%

Status 0 means the browser got no HTTP response it could read. It includes requests the page cancelled itself, as well as requests blocked by an extension or CORS, cancelled by navigation, or lost because the visitor went offline.
Errors by browser

Share of client-side errors, among the ten most common browsers recorded

Chrome: 61%

Safari: 21%

Firefox: 6.7%

Edge: 5.7%

Samsung Internet: 1.2%

Opera: 0.7%

Yandex Browser: 0.1%

Other: 3.1%

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

Based on 2,484,563 real-user page views. Real-user data since June 2026; browser errors since July 2026.

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 53% of jobs.

1.3 h
mean grace period before a late job counts as missed
13.1 h
mean time a missed job stayed missed
3,554
cron job monitors in the sample

How often jobs run

Share of heartbeat monitors by schedule interval

1 min or less: 15%

1–5 min: 53%

5–15 min: 9.1%

15 min–1 h: 8.3%

Over 1 h: 15%
How long a missed job stays missed

Missed runs by time until the job checked in again

Under 5 min: 45%

5–30 min: 26%

30 min–1 h: 8.3%

1–6 h: 9.2%

Over 6 h: 12%

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.7%
of domains expire within 30 days of 1 October 2026
8.2 yrs
mean age of a monitored domain
46%
end in .com, still the default
68%
have a registrar transfer lock

Most common endings

The 10 most common top-level domains, as a share of all monitored domains

.com: 46%

.org: 4.1%

.de: 3.7%

.net: 3.2%

.com.au: 2.1%

.co.uk: 2%

.dev: 1.8%

.io: 1.7%

.cz: 1.6%

.ch: 1.5%
Most common registrars

The 10 registrars holding the most monitored domains, as a share of all of them

GoDaddy: 16%

Cloudflare: 9.1%

Namecheap: 9%

Spaceship: 3.9%

Tucows: 2.8%

Porkbun: 2.6%

Global Domains International: 2.6%

Amazon Registrar: 2.2%

Network Solutions: 1.9%

Netregistry: 1.9%

Registry data came from RDAP for 86% of domains and from WHOIS for 11%. Based on 2,261 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.2%
of certificates expire within 14 days of 1 October 2026
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-256: 51%

ECDSA with SHA-256: 33%

ECDSA with SHA-384: 15%

RSA with SHA-384: 0.8%

Based on 74,609 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.

65,123
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 Processing: 5,692

Financial Services: 3,318

Security Operations: 3,069

AI & ML Platforms: 2,567

Education Technology: 2,547

VoIP & Communication: 2,451

E-Commerce: 2,379

Cloud Platforms: 2,329

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

Impact and timing are each provider’s own classification, taken from its status page. Separately, 35% of the outage reports visitors have submitted on Pulsetic’s public status pages since May 2026 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. What an hour of downtime costs depends on the business: in ITIC’s 2024 survey of more than 1,000 firms, it topped $300,000 for over 90% of mid‑size and large enterprises.

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

How these numbers are made

The rules behind every figure
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. Uptime figures are per monitor, averaged across monitors; the outage, real-user, cron, domain, SSL and dependency sections state their own sample size.
What this edition covers
- Window: 1 Oct 2025 to 1 Oct 2026
- Confirmed outages: 2,227,171
- Real-user page views (since June 2026): 2,484,563
- SSL certificates: 74,609
- Domains: 2,261
- Cron job monitors: 3,554
- Third-party status incidents: 65,123
Cite this report

“The State of Uptime 2026”, Pulsetic, https://pulsetic.com/uptime-statistics/, figures as of 1 October 2026.

Published under CC BY 4.0: quote, republish or adapt any figure, commercially too, with credit to Pulsetic and a link to this page.

Frequently asked questions

Can I cite this report?

Yes. The figures are published under the Creative Commons Attribution 4.0 license (CC BY 4.0): you may quote, republish and adapt them, commercially too, as long as you credit Pulsetic and link back to this page.
What is a good uptime percentage?

For a paid service, 99.9% (three nines) is the common baseline: about 8h 46m of downtime a year. 99.95% allows about 4h 23m and 99.99% about 52m 36s, which takes serious engineering investment. For comparison, the mean endpoint in this report was up 98.53%, about 5 days of downtime a year, and 72% of monitors reached 99.9% or better.
Which uptime metrics should I track?

Uptime percentage over a month and a year, the number of outages, and how long they take to fix: mean time to recovery, counted from when the failure begins, so detection time is included. Add response time, since a slow site can count as up, and the expiry dates of SSL certificates and domains, which take a site down on a known date. For scheduled jobs, track missed check-ins rather than uptime.
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?

The uptime and outage figures cover the 12 months from 1 October 2025 to 1 October 2026, a sample of 2,227,171 confirmed outages. The other sections have their own samples: 2,484,563 real-user page views, 74,609 SSL certificates, 2,261 domains, 3,554 cron job monitors and 65,123 third-party status incidents. Real-user data runs from June 2026, and browser errors from July 2026; visitor outage reports run from May 2026.
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?

Pulsetic recalculates the figures from live monitoring data once a month, on the 1st, over a rolling window, and this page checks for new figures every 15 minutes. The "Figures as of" date at the top of the page shows the latest recalculation; if you cite a figure, give that date.

Put your own website on the right side of these numbers

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed

The State of Uptime 2026

Key findings

How much of the time websites are up

Uptime, distributed

Uptime by check type

How long outages last, and when they start

How long outages last

When outages start

Outage starts by weekday and hour

Response time around the world

Where the time goes

By region

What real visitors experience

LCP loading

INP responsiveness

CLS visual stability

The errors that never reach your server logs

Failed requests by status

Errors by browser

Cron jobs and scheduled tasks

How often jobs run

How long a missed job stays missed

Domains: who registers them, and when they lapse

Most common endings

Most common registrars

SSL certificates: what signs them, and what lapses

Signature algorithms

The services you depend on

Incidents by category

What each number of nines allows

How these numbers are made

The rules behind every figure

Real checks, not a survey

Confirmed from another location

Blips excluded

Timestamps in UTC

Aggregated and anonymized

What this edition covers

Cite this report