Flower sites hit hard by Valentine’s Day

HeartValentine’s Day is a great day for any vendor selling flowers. Over the years, a large number of websites selling flowers have sprung up, and as you might expect, many of these websites are flooded by eager shoppers on February 14 wanting to buy flowers and gifts for their loved ones.

This is big business. Americans are expected to spend $18.6 billion on Valentine’s Day gifts this year.

Now here is the catch. Every year, some of these websites won’t be prepared to handle the increase in visitor traffic and as a result they slow down significantly, or even crash under the pressure.

Downtime and slowdown is extra bad for ecommerce sites

Webmasters failing to take expected (or unexpected) traffic spikes into account are all too common. For an ecommerce website, this is of course a very critical error. Just compare it with a regular real-life flower shop:

  • A slow website will turn away customers because it’s the equivalent of poor, slow service. That clerk seems to be ignoring you, or the line to the counter is moving in slow motion.
  • A crashed website is not only embarrassing, but is the same as completely closing shop with a big sign saying: “Go to some other shop and spend your money, we’re closed!”

Neither of the two is something a flower website would want to do on Valentine’s Day, one of the busiest days of the year, perhaps the busiest.

We here at Pingdom run an uptime monitoring service, so this year we decided to see how some of the more popular flower websites would handle themselves on, and in the days leading up to, Valentine’s Day. Would they hold up? Would they slow down a lot?

Slowdown and crashes

Several websites showed clear slowdown, especially in the morning hours of Valentine’s Day. A lot of last-minute orders in other words. Here are some very telling charts for three of the websites we monitored, Flower.com, Justflowers.com and Sendflowers.com.

Load time increase on Valentine's Day

We chose these three sites because they so clearly illustrate the increased load these sites are subjected to, and that it can actually noticeably affect the performance of a website. And note that this is just the load time of the HTML code of the website, without images. The overall load time was in other words even slower.

Out of the websites we monitored for this survey, one clearly stood out for two reasons. One was that it was generally much slower than the others, and second because it recorded a significant amount of downtime. More than eight hours in just the past few days, most of it on Friday afternoon, US time, when it was unavailable for four hours and then even more later in the evening.

That site was 1800flowers.com.

Website downtime, 1800flowers.com

Another site that also had downtime at a very bad time, almost and hour-and-a-half spread over the day on February 14, was 1stinflowers.com. The site also showed a similar increase in load time as you could see in the examples we included above.

Now, we’ve mentioned mainly sites where something went either wrong, or hinted at some kind of performance issue or degradation due to the increase in traffic. But, there were sites that worked just fine, with no noticeable issues. These include Proflowers.com, Shop.marthastewart.com, Hallmark.com and Findaflorist.com.


Downtime and slowdown can and will happen to all websites. However, sometimes the timing can be very bad, and a flower website having problems during business hours on Valentine’s Day, or even the days leading up to Valentine’s Day, is a prime example of bad timing.

In most cases this could likely have been avoided if the websites had been better prepared to handle the additional traffic. Instead, some of these sites have ended up losing sales and goodwill (slow websites tend to be quite a frustrating experience).

By the way, if you are interested in digging into the data yourself, or keep an eye open over time, we’ve set up a public, continuously updated report page: U.S. Flower Websites, uptime and response time status page. There you can find all the sites included in this survey, including some we didn’t mention.


  1. Good write-up. Raises an interesting question though: what particular dependency was “out” during the outage for 800flowers.com. We tracked that site as well (for a custom index) and have GOOD datapoints right through the outage you are seeing. How many origins did you come from (a lot I would guess). The only thing I can see that differs between our measurements and yours is that we targetted “www.1800flowers.com” and you targetted “1800flowers.com”, but both lead to the same redirects that get you to a ww#.1800flowers.com server (such as ww10.) Thoughts? Happy to share more data. Here is a scatter plot and a single drilled-down waterfall view of all elements including redirects:

    Scatter plot through the “outage” you observed (my times in PST):


    Waterfall chart with redirects and page objects taken during “outage” (again, my times are PST):

    1. @Dave: Thanks for chiming in. This is very interesting. We simply loaded the HTML code of the page, no images, etc, and we did the test once per minute, from 25 different locations (rotated, not all at once). When things failed for that site on the 11th, the two things we could see was that the HTML page either became exceedingly slow to load (we count anything slower than 30 seconds as down, which is quite generous, and in the extra automated tests we do I can find examples where it took way over a minute to load), or in some cases their server(s) would not respond at all. The redirect would happen, but then no more. And needless to say, all locations showed the same problem reaching their website during these very long periods of time (more than 6 hours total on Friday). See here for detail: http://stats.pingdom.com/l8ebmyrsjqk8/297469/2011/02

      Then there’s the general methodology. I don’t know how you present yourself to them when you do am HTTP Get request. We present them with our Pingdom user agent in the request header, we don’t pretend to be a specific web browser like IE or Firefox (although we can do that, but it’s not our default monitoring behavior since it simplifies filtering, etc, for customers). And it clearly works normally for the site, so why would it suddenly stop and for such a long time, then resume?

      As you said, we monitored http://1800flowers.com/ and you monitored http://www.1800flowers.com/ but as you say, it shouldn’t make a difference. Both are redirected.

      So, what exactly did you measure? How do you access their site?

  2. Very odd differences indeed. We used our Transaction Perspective product here, which launches an actual browser session (either IE or Firefox) and would have taken physical screenshots if there had been errors, but we got good pages in all but one of our measurements (more on that below).

    In this case, we visited the site starting at “www.1800flowers.com” every 15 minutes from each of 10 geographically dispersed locations on six different networks: Boston (Verizon), Chicago (Savvis), Dallas (AT&T), Detroit (Level3), Houston (Level3), Los Angeles (AT&T), New York (Sprint), Philadelphia (Verizon), San Francisco (Sprint) and Washington D.C (Qwest). My locations in this case were all domestic. What was the mix of locations and networks for the failures you encountered?

    At 15 minute intervals from each location and 10 locations, we made 40 visits per hour. I’ll provide a scatterplot here with a broader time range to match up with the earliest and latest outage your agents found on the 11th (my times are in PST, but I’ve done the math to catch your EST range):


    The above wider scatter-plot shows a single long-running visit that timed out after 60 seconds.

    If you were logged in, you would be able to click through that one red diamond to drill down. I’ll put up a sharable copy of the the waterfall diagram, with element-by-element stats, a screenshot and capture of HTTP headers exactly as IE encountered them:


    Note: the page never did render, as you can see from the screen capture we performed. Clearly THIS one’s is a failure, but it’s bracketed by perfectly normal measurements on either side.

    I’m left wondering, as you were, whether it is possible that 1-800-Flowers briefly stopped supporting visits by your Pingdom agent. I agree that seems pretty unlikely, unless they have some highly impressive “velvet rope” mechanism that starts shutting out robots when traffic gets heavy.

    In the end, SOMETHING stopped honoring the connection requests and redirects for your agents and the spontaneously started working a while later. In the mean time, the same thing didn’t prevent real browsers from getting through.

    Like so many things in romance, this one is a mystery 🙂

    1. @Dave: Thanks for expanding on your reasoning. Interesting, and very strange indeed. You may be right in that for some reason the Pingdom user agent in the HTTP request header could have been a factor, but that would have been outside of our control. Something did stop working from our monitoring perspective, and from all our locations at that, so for some reason our HTTP requests were not let through properly by 1800flowers.com during this period (a problem we didn’t see with any of the other monitored sites, I might add).

      Regarding user agents, our users can of course modify the user agent to anything they like, including that of a normal web browser, but as mentioned we use our own user agent as default to make it as easy as possible for webmasters to filter out any visits from Pingdom if they like.

Leave a Reply

Comments are moderated and not published in real time. All comments that are not related to the post will be removed.