Synthetic Monitoring

Simulate visitor interaction with your site to monitor the end user experience.

View Product Info


Simulate visitor interaction

Identify bottlenecks and speed up your website.

Learn More

Real User Monitoring

Enhance your site performance with data from actual site visitors

View Product Info


Real user insights in real time

Know how your site or web app is performing with real user insights

Learn More

Infrastructure Monitoring Powered by SolarWinds AppOptics

Instant visibility into servers, virtual hosts, and containerized environments

View Infrastructure Monitoring Info
Comprehensive set of turnkey infrastructure integrations

Including dozens of AWS and Azure services, container orchestrations like Docker and Kubernetes, and more 

Learn More

Application Performance Monitoring Powered by SolarWinds AppOptics

Comprehensive, full-stack visibility, and troubleshooting

View Application Performance Monitoring Info
Complete visibility into application issues

Pinpoint the root cause down to a poor-performing line of code

Learn More

Log Management and Analytics Powered by SolarWinds Loggly

Integrated, cost-effective, hosted, and scalable full-stack, multi-source log management

 View Log Management and Analytics Info
Collect, search, and analyze log data

Quickly jump into the relevant logs to accelerate troubleshooting

Learn More

How fast and reliable is your Feedburner RSS feed?

A huge number of blogs use Feedburner to syndicate their RSS feeds. Since the service was launched in 2004, it’s pretty much become the de facto standard for this. With so many bloggers relying on Feedburner, reliability and performance is of course extremely important. RSS feeds, just like websites, need to be available all the time on the Web.
If you’ve been following the development of Feedburner, you’ll know that the company was bought by Google a while back, and as of late this February, Google is serving all Feedburner feeds on its own infrastructure. (If you’re curious about Feedburner’s old infrastructure, check out this article.)

Testing Feedburner’s RSS feed performance

We monitored the loading time and availability of the Feedburner RSS feed for our own blog:
Since Google presumably uses the same infrastructure for all Feedburner feeds, that should be indicative of the overall performance of Feedburner feeds in general.
The tests were performed once a minute with our uptime monitoring service, testing from locations in Europe and North America. (We’d like to point out that robots accessing Feedburner feeds don’t affect the subscriber count.)
Now that we’ve been monitoring the RSS feed for over two months, we thought it was a good time to have a look at the results and see how Google is handling Feedburner’s feed delivery performance so far.

Feed availability: Not bad but room for improvement

We started the monitoring in March (on the 9th, to be precise). Counting until now, May 12, the tested feed has been unavailable for a total of 53 minutes, resulting in 99.94% uptime (availability).
A 99.94% uptime means that the feed will be unavailable for 5 hours and 15 minutes over the course of a year. This is actually not bad, although considering the resources of Google, it can probably improve this number significantly.
Most of the problems appear to be short, temporary issues. The longest outage was a mere 13 minutes, the second-longest was 10 minutes, and the vast majority were around a minute (we detected 18 outages in total). The longer-lasting problems were due to severe slowdown (if we couldn’t load a feed in 30 seconds, we counted it as unavailable).
The shorter problems, or glitches if you like, were sometimes due to HTTP error 502 (bad gateway). The error message from Google when this happens is: “There was a problem retrieving the feed: Deadline exceeded retrieving from Bigtable.”
Bigtable is Google’s proprietary database system.
The resulting error page that you get instead of the feed looks like this (yellow emphasis added by us):

A note regarding the strange feed address in the image above: The original page had the correct feed address, but this screenshot was generated from a saved HTML page in the Pingdom control panel (this is part of an automatic error analysis when our system finds an error). Due to Javascript code in the Feedburner error page the feed address above is wrong (what you see is the address to the control panel page). Just in case you found that part confusing. 😉
Other errors we detected were HTTP error 500 (internal server error) and as previously mentioned, timeouts. This is the resulting page from the 500 error:

Feed loading time: Gradually improving?

Over the period, the average loading time for the feed was 0.8 seconds. This is the average across all locations, both in Europe and North America.
As you can see in the below graph, Google seems to have gradually improved the overall performance of the Feedburner feed. When we started our tests in March the average load time for the feed was over a second on average, but after that performance has gotten better.
There was a period of significant slowdown the last couple of days in March, but after that performance has been relatively stable. Note that the values in the graph are averages counting over an entire day.

Unfortunately we don’t have any data on how the feed loading speed was on the old Feedburner infrastructure. It would have been interesting to compare.


Feedburner (now Google) has had its fair share of problems with the reporting part of its service, most recently at the beginning of April. However, here we only looked at being able to properly access and load the RSS feed itself (essential for feed readers). We have to say that Feedburner definitely gets a passing grade, although both uptime and performance has room for improvement. Google says it’s still working on improving Feedburner behind the scenes, so it will be interesting to see what happens in the coming months.
All monitoring in this survey was done with the Pingdom uptime monitoring service. For a feed to count as unavailable, it had to fail to load from two different locations.

Exit Rate vs Bounce Rate – Which One You Should Improve and Why

Tracking your website’s exit and bounce rates will give you insight into how [...]

Introduction to Observability

These days, systems and applications evolve at a rapid pace. This makes analyzi [...]

Webpages Are Getting Larger Every Year, and Here’s Why it Matters

Last updated: February 29, 2024 Average size of a webpage matters because it [...]

A Beginner’s Guide to Using CDNs

Last updated: February 28, 2024 Websites have become larger and more complex [...]

The Five Most Common HTTP Errors According to Google

Last updated: February 28, 2024 Sometimes when you try to visit a web page, [...]

Monitor your website’s uptime and performance

With Pingdom's website monitoring you are always the first to know when your site is in trouble, and as a result you are making the Internet faster and more reliable. Nice, huh?



Gain availability and performance insights with Pingdom – a comprehensive web application performance and digital experience monitoring tool.

Start monitoring for free