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.90%, about 4 days of downtime a year, and 82% 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 website can count as up, and the expiry dates of SSL certificates and domains, which take a website 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 November 2025 to 1 November 2026, a sample of 2,356,248 confirmed outages. The other sections have their own samples: 3,725,636 real-user page views, 75,540 SSL certificates, 3,047 domains, 3,937 cron job monitors and 72,543 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 Nov 2025 to 1 Nov 2026 · Checks from 15 locations · Figures as of 1 Nov 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.90%

mean uptime across every monitored endpoint
54.1%

of monitors had at least one confirmed outage
47%

of outages were over in under 5 min
90.7%

of outages were resolved within an hour

Key findings

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

Endpoints monitored by Pulsetic averaged 98.90% uptime (the mean across monitors) in the 12 months to 1 November 2026, about 4 days of downtime a year at that average, while more than half of monitors (76%) round to 100% uptime.
54.1% of the endpoints Pulsetic monitored had at least one confirmed outage in the 12 months to 1 November 2026.
Of the 2,356,248 outages Pulsetic confirmed in the 12 months to 1 November 2026, 47% were over in under 5 min and the median outage lasted 5–30 min; the mean was 4.7 h, pulled up by the 2.2% that ran over 6 h.
90.7% of the outages Pulsetic confirmed in the 12 months to 1 November 2026 were resolved within an hour.
The mean HTTP check Pulsetic ran in the 12 months to 1 November 2026 took 667 ms; by the region the check ran from, Europe was fastest at 477 ms and Africa slowest at 1,102 ms.
Pulsetic’s real-user monitoring, which has recorded browser errors since July 2026, logged about 110 JavaScript exceptions and 17 failed HTTP responses (status 400 or above) per 1,000 page views, figures as of 1 November 2026.
1.5% of the 75,540 SSL certificates Pulsetic monitors expire within 14 days of 1 November 2026, and 0.1% were already expired or invalid.
Across the 4,387 third-party services whose public status pages Pulsetic follows, providers reported 72,543 incidents, with a median of 2.0 h to resolve, figures as of 1 November 2026.

How much of the time websites are up

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

51
mean number of confirmed outages per affected monitor
76%
of monitors round to 100% uptime
4.2%
of monitors were up less than 95% of the time

Uptime, distributed

Share of monitors in each uptime band

Rounds to 100%: 76%

99.9–100%: 5.6%

99.5–99.9%: 7.5%

99–99.5%: 3.1%

95–99%: 3.7%

< 95%: 4.2%

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.

Ping (ICMP): 98.97% up

HTTP(S): 98.56% up

TCP port: 97.82% up

TCP port monitors spent 2.1× as much time down as Ping (ICMP) monitors.

How long outages last, and when they start

47% of confirmed outages were over in under 5 min, and 90.7% within an hour. The median outage lasted 5–30 min. The mean time from first failure to recovery was 4.7 h, pulled up by the long tail: 9.3% of outages ran longer than an hour and 2.2% over 6 h. A monitor that had outages averaged 51 of them over the 12 months, so about 13 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.7 h
mean time from first failure to recovery
9.3%
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: 47%

5–30 min: 37%

30 min–1 h: 7%

1–6 h: 7.2%

Over 6 h: 2.2%

When outages start

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

Outage starts per hour ranged from 83,812 at 03:00 UTC to 111,673 at 15:00 UTC. 23% of outages started between 00:00 and 06:00 UTC.

Show the numbers

Hour (UTC)	Outage starts
00:00	98,181
01:00	90,954
02:00	91,727
03:00	83,812
04:00	89,442
05:00	91,461
06:00	97,461
07:00	106,866
08:00	102,430
09:00	101,658
10:00	106,284
11:00	99,864
12:00	107,943
13:00	109,761
14:00	110,559
15:00	111,673
16:00	103,824
17:00	97,522
18:00	96,064
19:00	93,410
20:00	91,494
21:00	92,806
22:00	90,395
23:00	90,657

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,989 outage starts, and the quietest was Sunday 11:00 UTC, with 10,909.

Show the numbers

Hour (UTC)	Mon	Tue	Wed	Thu	Fri	Sat	Sun
00:00	14,144	13,440	13,801	15,646	14,694	13,059	13,397
01:00	12,212	12,910	13,506	14,105	13,194	12,129	12,898
02:00	11,851	13,058	13,439	14,124	13,838	11,929	13,488
03:00	11,293	12,067	12,680	13,046	12,214	11,050	11,462
04:00	11,983	12,570	13,716	13,349	13,277	12,223	12,324
05:00	12,199	13,021	14,836	13,791	13,792	11,431	12,391
06:00	13,633	14,411	14,690	14,302	15,510	12,183	12,732
07:00	16,722	16,161	15,932	16,717	16,847	12,697	11,790
08:00	15,887	15,900	15,694	15,152	15,372	12,020	12,405
09:00	16,342	15,574	15,275	15,209	15,144	12,445	11,669
10:00	15,341	15,600	16,844	15,339	18,281	12,216	12,663
11:00	14,464	18,034	15,259	15,124	14,458	11,616	10,909
12:00	14,756	20,441	15,921	17,925	14,489	12,719	11,692
13:00	15,416	20,989	17,202	17,627	15,129	12,324	11,074
14:00	17,052	17,452	16,816	17,746	15,888	13,238	12,367
15:00	16,105	17,663	17,769	18,043	16,071	13,068	12,954
16:00	16,277	17,206	16,242	16,250	14,354	12,257	11,238
17:00	14,190	15,012	15,992	15,025	13,654	12,265	11,384
18:00	13,896	14,999	16,198	14,653	12,950	11,956	11,412
19:00	13,247	13,860	16,517	13,542	12,540	12,091	11,613
20:00	13,042	14,353	15,034	14,071	12,154	11,866	10,974
21:00	12,718	14,594	15,925	13,735	12,016	12,786	11,032
22:00	13,093	13,665	14,596	13,510	12,349	12,118	11,064
23:00	12,675	12,825	13,590	13,241	11,908	12,149	14,269

Based on 2,356,248 confirmed outages from 1 November 2025 to 1 November 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 667 ms from start to finish, and the biggest share of it was server wait.

667 ms
mean response time, across every HTTP check
477 ms
mean for checks run from Europe, the fastest region
1,102 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.

40 ms

DNS lookup
54 ms

TCP connect
70 ms

TLS handshake
379 ms

Server wait
121 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	477 ms	99.02%
North America	522 ms	99.12%
South America	899 ms	98.65%
Asia/Australia	1,088 ms	98.40%
Africa	1,102 ms	98.75%

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): 69% 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: 67%

Mobile: 67%

75th percentile

Desktop: 2.55 s
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: 69%

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: 83%

Mobile: 85%

75th percentile

Desktop: 0.06

Mobile: (+31% vs desktop) 0.08

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.

110
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 269.3 recorded errors per 1,000 page views, of which 41% were JavaScript exceptions and 59% 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%

422 Unprocessable Content: 3.2%

400 Bad Request: 2.5%

403 Forbidden: 1.4%

404 Not Found: 1.4%

429 Too Many Requests: 0.9%

502 Bad Gateway: 0.7%

500 Internal Server Error: 0.3%

504 Gateway Timeout: 0.2%

401 Unauthorized: 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: 62%

Safari: 21%

Firefox: 6.4%

Edge: 5.2%

Samsung Internet: 1.3%

Opera: 0.9%

Other: 3.3%

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

Based on 3,725,636 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 49% of jobs.

2.7 h
mean grace period before a late job counts as missed
15.0 h
mean time a missed job stayed missed
3,937
cron job monitors in the sample

How often jobs run

Share of heartbeat monitors by schedule interval

1 min or less: 11%

1–5 min: 49%

5–15 min: 9.1%

15 min–1 h: 10%

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

Missed runs by time until the job checked in again

Under 5 min: 41%

5–30 min: 27%

30 min–1 h: 8.7%

1–6 h: 9.9%

Over 6 h: 13%

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.

3.6%
of domains expire within 30 days of 1 November 2026
8.6 yrs
mean age of a monitored domain
46%
end in .com, still the default
65%
have a registrar transfer lock

Most common endings

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

.com: 46%

.ch: 6.6%

.org: 3.8%

.de: 3.2%

.net: 3%

.co.uk: 1.6%

.is: 1.6%

.com.au: 1.5%

.io: 1.4%

.dev: 1.4%
Most common registrars

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

GoDaddy: 20%

Namecheap: 9.2%

Cloudflare: 8.2%

Spaceship: 3.8%

Tucows: 3%

Porkbun: 2.3%

Network Solutions: 2%

Squarespace Domains II: 2%

Global Domains International: 1.9%

Amazon Registrar: 1.9%

Registry data came from RDAP for 81% of domains and from WHOIS for 16%. Based on 3,047 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.5%
of certificates expire within 14 days of 1 November 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 75,540 monitored certificates.

The services you depend on

Pulsetic follows the public status pages of 4,387 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.

72,543
incidents reported by tracked services
2.0 h
median time for a service to resolve an incident
33%
were rated major or critical by the provider
1.8%
were planned maintenance rather than outages

Incidents by category

The eight categories that reported the most incidents

Payment Processing: 8,158

Financial Services: 3,906

Security Operations: 3,307

Cloud Platforms: 3,183

VoIP & Communication: 3,118

AI & ML Platforms: 2,903

E-Commerce: 2,609

Education Technology: 2,503

The other 147 categories reported 42,856 incidents between them.

Impact and timing are each provider’s own classification, taken from its status page. Separately, 34% 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 Nov 2025 to 1 Nov 2026
- Confirmed outages: 2,356,248
- Real-user page views (since June 2026): 3,725,636
- SSL certificates: 75,540
- Domains: 3,047
- Cron job monitors: 3,937
- Third-party status incidents: 72,543
Cite this report

“The State of Uptime 2026”, Pulsetic, https://pulsetic.com/uptime-statistics/, figures as of 1 November 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.90%, about 4 days of downtime a year, and 82% 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 website can count as up, and the expiry dates of SSL certificates and domains, which take a website 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 November 2025 to 1 November 2026, a sample of 2,356,248 confirmed outages. The other sections have their own samples: 3,725,636 real-user page views, 75,540 SSL certificates, 3,047 domains, 3,937 cron job monitors and 72,543 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