Why observability needs to come with answers
Performance monitoring tools have long been able to tell you that your website is slow. Far fewer can tell you exactly why — and almost none can fix the problem from the same screen. For teams responsible for modern web experiences, where even 100 ms of latency can measurably hurt revenue and engagement, that gap between diagnosis and treatment is costly.
Cloudflare's answer is Observatory, now in open beta across all subscription tiers including Free. The tool unifies real-user metrics, backend telemetry, error rates, cache hit ratios, and synthetic tests into a single dashboard. What sets it apart is that it pairs each finding with a recommended action, and in many cases lets you apply the fix immediately via the new Smart Shield product, also available today on all plans.
A dataset that spans a fifth of the web
Cloudflare's vantage point is unique: it handles traffic for over 20% of the web every day. Observatory draws on that scale to combine data that typically lives in separate tools, creating an end-to-end view of application health. The launch brings together five data sources:
- Real-user data: How the application performs for actual visitors in real-world conditions.
- Backend telemetry: A breakdown of a request's lifecycle to locate bottlenecks.
- Error rates: Stability signals at both the edge and the origin.
- Cache hit ratios: Whether your configuration is extracting maximum performance.
- Synthetic testing: Simulated tests of key endpoints under controlled conditions.
Real-user data as the source of truth
Real-user monitoring (RUM) collects performance metrics from actual traffic. It is inherently unpredictable, covering every scenario and device your visitors use. That makes it the most accurate representation of user experience, and it is the first thing you see when opening Observatory.
Synthetic data, by contrast, comes from simulated tests running under predefined conditions — a set location, network speed, and browser profile. Those tests produce clean, consistent baselines, but they are always approximations. They miss the sporadic, real-world issues that only genuine traffic reveals.
Observatory prioritizes RUM data, with particular attention to Core Web Vitals. To make this data broadly accessible, Cloudflare is enabling its privacy-first web analytics by default for all free zones — no setup required — with the exception of visitors from the EU or UK.
Tracing the backend behind the metrics
Front-end metrics like Core Web Vitals are excellent key performance indicators, but they are not enough on their own. When a KPI regresses, you need diagnostic data to understand why. Backend telemetry fills that role, and Observatory gives it particular attention.
Time to First Byte (TTFB) has fallen out of favor as a primary metric, yet it remains a valuable diagnostic. Cloudflare analyzed over 9 billion RUM events and found a strong correlation between TTFB and Largest Contentful Paint (LCP). Compared to the average site, sites with a "poor" TTFB (over 1800 ms) are:
- 70.1 percentage points less likely to have a "good" LCP
- 21.9 percentage points more likely to have a "needs improvement" LCP
- 48.2 percentage points more likely to have a "poor" LCP
Errors, cache ratios, and the origin effect
Performance and stability problems often trace back to configuration changes or rising error rates. Observatory surfaces cache hit ratios and error rates for both the edge and the origin, helping you spot where things go wrong.
Cache performance data reinforces a familiar principle: serving content from the edge is faster. Across the same 9 billion data points, 91.7% of pages served from Cloudflare's cache achieved a "good" TTFB (≤800 ms), compared to 79.7% for requests served from the origin server. Moving content to the edge and improving origin response times are among the most reliable paths to a stronger performance baseline.
Synthetic tests with a histogram mindset
Synthetic testing complements RUM with controlled, repeatable conditions. The data is less noisy, and lab environments allow for richer instrumentation than production traffic alone. Observatory offers two types of synthetic tests.
Browser tests load a page in a headless browser, run Google's Lighthouse, and report on key performance metrics with suggestions for improvement.
Network tests are a new addition. Each test targets a specific endpoint and records wait time, server response time, connection time, SSL negotiation time, and total load time. Rather than returning a single data point, network tests run a series of individual requests spread over a short period. Results are presented as a histogram, showing the full distribution of outcomes — not just the average.
You can select two completed network tests to compare their histograms side by side, making it easier to evaluate changes over time or across configurations.
Both test types are slated for improvements in Q4 2025 to make them more powerful and diagnostic. Cloudflare also intends to open-source many of the testing agents that power Observatory, citing a belief that open scrutiny is the best way to ensure measurement tools are accurate and trustworthy.
From Metrics to Fixes: Smart Suggestions in Observatory
Observatory is designed to close the gap between identifying a problem and knowing what to do about it. For every metric, we want to pair the data with prescriptive, data-driven advice — not generic guidance. This focus on actionability is why we're introducing Smart Suggestions.
A useful example is how we handle Largest Contentful Paint (LCP), a core web vital that tracks when the largest piece of content on a page — whether an image, video, or text — is displayed. By itself, LCP is a black box. A slow LCP could be caused by server response time, render-blocking code, or a large media file. Without more detail, it is hard to offer anything beyond vague recommendations.
To change that, we break LCP into subparts, much like TTFB:
- Time to First Byte: how quickly the server responds to the HTML request
- Resource Load Delay: how long after TTFB until the browser discovers the LCP resource
- Resource Load Duration: how long the browser takes to download that resource
- Render Delay: how long to render content once the resource is available
In the example above, the recommendation engine analyzes real-user data and identifies that Resource Load Delay accounts for more than 10% of total LCP time. That indicates the LCP resource is likely large and could benefit from compression, so the suggestion is to enable Polish. Expanding the library of these patterns and solutions will be a constant focus, with more content planned for Q4.
Smart Shield: One Tool for Origin Protection
Insight is only half the battle. Acting on it requires protecting your origin, and for many customers, managing origin routes and connections is the biggest factor in overall performance. When a request has to go back to the origin, user-facing metrics suffer. Today, achieving the basics — faster applications, reduced origin load, health visibility, and restricted origin access — means navigating multiple APIs and dashboards. Smart Shield changes that.
Smart Shield combines the essentials of origin protection — dynamic traffic acceleration, intelligent caching, health monitoring, and dedicated egress IPs — into one place with a unified API and UI. It integrates with Observatory so you get both the diagnostic "what" and the remedial "how": Smart Shield delivers the capabilities that improve performance, availability, and security. Observatory identifies problems, Smart Shield applies solutions, and real-time analytics verify the results.
The benefits for customers are clear:
- Reduced total cost of ownership (TCO)
- Faster time-to-value (TTV) for performance, availability, and security issues
- Confidence to enable new features, with effectiveness validated in the data
Your engineers should spend time building user experiences, not becoming configuration experts.
Smarter Origin Connections
One of the most significant drivers of origin performance is connection management. A sudden traffic surge can trigger a flood of TLS handshakes that overloads the origin or stalls requests. Cloudflare has reworked how its network communicates with customer origins to dramatically improve connection reuse.
Previously, Cloudflare made requests to origins from a pool of machines in each data center that was sized identically by default for every application. Custom sizing required manual intervention, and defaults were often suboptimal — either too many machines caused cold connection pools, or high-traffic applications exceeded the default pool's capacity, leading to incidents that required engineers to manually increase the fanout factor.
Now, pool sizes are determined automatically based on domain-level traffic volume in a data center. The system scales the machine count up or down to match the load for each customer, and it can react to changes in traffic patterns within seconds. A high-volume API site no longer uses the same machine footprint as a typical smaller site.
These changes deliver measurable results. Cloudflare now uses over 30% fewer connections across the board to reach origins — saving roughly 402 years of handshake time per day across global traffic, or nearly 12,060 years per month. For individual customers, that translates to an average 30% reduction in origin connections, with lower load on origin infrastructure and reduced egress fees. In some cases the improvement is much larger: one data center heavy with API traffic saw a reduction in origin connections of about 60%.
Every connection to an origin consumes compute and time for TCP and SSL handshakes, which competes with serving user content. These reductions remove that hidden tax on application performance. More Smart Shield updates are coming at the start of 2026, including self-serve support for dedicated CDN egress IP addresses.
The Road Ahead
With the beta launch of Observatory, the focus now shifts to expanding both data depth and actionable paths. The goal is for Observatory to become the single source of truth for application health, offering a truly comprehensive picture. Upcoming work includes:
- Deeper, more diagnostic data: breaking down every aspect of the request and page lifecycle to provide more granular metrics.
- More paths to solutions: expanding the suggestion library with precise, data-driven fixes, and tightening the feedback loop so configuration updates can be validated instantly through Smart Shield.
- Benchmarking against other products: making it easier to compare the performance of split traffic across CDNs, an issue that arises for customers with regulatory or compliance constraints.
Observatory and Smart Shield are available today. We want to hear your feedback on how these products can better serve your needs.
