On Resilience … Or, Welcome Back, Amanda

One of the joys of being in a small, tightly knit company like FeedBlitz is that, as colleagues, we grow close to each other.  We share our triumphs and joys; and we circle the wagons when the going gets tough. In reality, on balance, 2014 was more tough than not for the FeedBlitz crew.

Of course, like any community, we don’t often share the hard times publicly.  We struggle, we manage, we support each other, and with luck nobody on the outside notices. Nothing unusual, really, in that.

There are, however, some things — even the tougher ones — that are very much worth noticing.

And so it is today.

Today, we welcome Amanda Henson back to work in our customer service organization after spending most of 2014 fighting breast cancer. You can read about her journey, her resilience, her reality, on her personal blog.

Resuming normal work is a hugely important milestone for Amanda in her recovery; a major step in reclaiming normality.

Although her treatments are not over, today that step has been taken. With which, I think, enough said from me.

Except for this:

Welcome back, Amanda. We’ve missed you. We’re so very glad you’re here.


Malware Warnings


Looks like the reviews have completed and things are back to normal. Some systems will cache the earlier results, and the updates may take a while to roll out. If you’re still seeing warnings, please try Ctrl+F5 to refresh your browser’s local cache.

Original Post

If you’re seeing a “malware warning” when clicking through to FeedBlitz this morning, yikes, that can be scary. For the record, rest assured, we are safe; we have a review pending with Google this morning. Meanwhile it IS safe to click through, FeedBlitz itself hasn’t been damaged and isn’t sharing malware.

What happens is that Google’s search bots visit links on the web, and one of the things they do is report not only compromised sites (not FeedBlitz!), but sites that link to compromised sites. With our extensive email archives and tens of thousands of feeds, sometimes FeedBlitz will link to a third party site that becomes infected (almost always a site linked to in one of our client’s posts, so two steps removed, as it were).  In that case a URL here gets flagged by Google in Webmaster Tools, because we track all clicks to generate metrics. It’s that which makes us appear to be part of the problem, when we’re not, because that tracking has to run through a feedblitz.com site first for it to work.

We check these flagged links daily, and update our list of blocks, so that we don’t redirect your and our visitors to bad places on the Web, as first discussed here.

Overnight, it seems that Google’s bots determined that several poorly maintained sites that some of our publishers link to were bad. That’s OK, it’s routine, we deal with that daily. What isn’t OK is that their algorithms somehow decided that FeedBlitz itself was possibly bad. We aren’t, obviously, but that means until the review completes (up to 24 hours) some folks will see an unpleasant warning in the browsers. That’s crappy and I’m sorry. It happens to the best of us now and again, it’s part of the hazards of being in this industry.

We all want a safer, trustworthy web. Sometimes the automation can be overzealous with downstream freakout results. That stinks. But I am confident that this will be done in less than a day.

Meanwhile, all is well, truly. It’s safe to click on a FeedBlitz feed or link, and the warnings will be gone soon.

.@Wistia videos now supported in FeedBlitz emails

Video in email is a pain. Unless you’re an HTML5 guru and only want your emails working on iOS devices, video just plain doesn’t work in email.

FeedBlitz has long supported video providers such as YouTube and Vimeo and more, by automatically converting videos from these systems into thumbnails that work great in email.

Today, we’ve added up-and-comer Wistia to the list of supported video services. So if you are on the FeedBlitz web site, what you see next is a Wistia corporate video in their video player. If you get this via email, however, you’ll see a thumbnail instead.


Hurry up and Wait: Delayed Gratification for Autoresponders

FeedBlitz has offered comprehensive, multi-step autoresponders for years now. They’re great for saying thanks, delivering incentives, or offering multi-step courses. Couple an autoresponder sequence to other lists using FeedBlitz’s triggers, start a signup with a parser, and you’ve got a very capable automated email marketing solution.

A typical autoresponder sequence starts immediately. You sign up for a list, and your incentive is delivered right away. You make your purchase, et voila! A thank you missive is en route, toute suite. It’s what people expect to happen.

But what if you have a fixed sequence that you want to send, but instead of starting immediately, you want to delay until next Thursday, say, regardless of when the subscriber took the action that got them onto the autoresponder in the first place? Tough to do with an autoresponder series that always starts instantly, no matter what time of day (or night) the subscriber joins.

Enter a new feature here at FeedBlitz: The ability to delay an autoresponder’s start. If you go to your autoresponder’s dashboard, or enter its article sequence edit page, you will see that, by default, it is defined to begin immediately. Click the “immediately” link, and you can choose the day and time the autoresponder should actually start. Simple.

Want the best of both worlds, i.e. an immediate “thank you” and then a delay? Well, you can do that too. First, create both your autoresponders (the “ASAP” one and the delayed one). From the ASAP autoresponder’s dashboard, on the “Subscriber Management” tile, click “Triggers” and then add a “Completion” trigger to add the subscriber to the delayed sequence. ASAP does what it does right away, and then hands the subscriber off to wait for the start of the delayed sequence.

So long, Zombie Google Reader

We all know how to stop a zombie, right? Get it in the head. Fine in the movies or “The Walking Dead,” but it’s not so simple for zombie products or technologies.

Case in point: Google Reader. The product was “killed” by Google in the middle of 2013, and it was no longer available to end users. So it was dead and buried, right?

Wrong. It was a zombie. The back end of Google Reader kept on plugging away, checking feeds, dutifully reporting how many subscribers it was polling on behalf of. Like the Energizer bunny, It kept on going and going and going … until sometime on November 13th, 2014, when some plucky soul at Google finally whacked the Google Reader back end firmly enough in the head to stop it for good.

Yes, for nearly a year and a half, the back end of Google Reader apparently didn’t know that it was dead.

After its nominal demise, last year, we made a decision to continue to report Google Reader subscriber numbers while we still saw them. So if your RSS stats changed dramatically on November the 14th, the first full day without Zombie Google Reader (ZGR), that’s why.

It’s weird and odd that ZGR was left running for so long; makes me wonder what happened to make someone finally turn it off. Maybe that famous pink marketing bunny took its batteries back.

For the Fallen – We Will Remember Them

They shall grow not old, as we that are left grow old:
Age shall not weary them, nor the years condemn.
At the going down of the sun and in the morning
We will remember them.

From “For the Fallen” by Robert Laurence Binyon

For the benefit of my mostly US audience, in the UK and many other countries we buy paper poppies around the 11th to commemorate those who served and those who fell during the World Wars. The poppies specifically memorialize the killing fields in France and Belgium during WWI where the “lions led by donkeys” on both sides killed each other in unimaginable numbers. Day in, day out. Only the Spanish Flu of 1918 outkilled the machine guns, mustard gas and barbed wire.

Today, then, is a noteworthy day in Europe, where the slaughter of the horribly misnamed “Great War” mostly took place between 1914 and 1918. Today, entire countries largely fall silent at 11am on November 11th to remember the wars, their dead, the valor of those who served and the bravery those who still do. It’s a day of respect, retrospect and introspection.

In churches and schools, at services, memorials and cenotaphs in the cities, towns and villages, the stanza from Binyon’s poem, quoted above, is often spoken as part of memorial services and readings. The focus back in Britain is markedly different today – a day that’s somber, one of mourning not celebration – than Veteran’s Day is here in the US, my adopted home. It has always been this way: Armistice Day has never been a celebratory day off. It’s not a day to celebrate the military like it is here in the States (which is not to say it is necessarily better; it’s just a different perspective).

In that spirit then, no matter what your politics, no matter where you live today, no matter what else you are doing or celebrating this November 11th, I would ask only this: Please take a moment today to remember the Fallen and their sacrifices, no matter where they fell nor for what cause.

Let us make it so that, for today at least, we will remember them.

They shall grow not old, as we that are left grow old:
Age shall not weary them, nor the years condemn.
At the going down of the sun and in the morning
We will remember them.

Resolved: Overnight click-through issues

Although feeds were being served and email sent OK, some publishers experienced click-through issues overnight; the problem has now been resolved. We’re sorry for any inconvenience. Any subscribers seeing an error message now need to simply refresh the page.

Today, job 1 is to update our monitors to better detect this kind of issue, which unfortunately went undetected by our automated system health tracking.

The One Easy Gmail Tip for Tracking and Testing

We recently sponsored the slightly-awkwardly-named-but-totally-worthwhile Type-A Parent Conference in Atlanta, and so naturally the topic of email came up (surprise!), especially in relation to testing email forms with different email accounts. It can be a real pain to create yet another email address for your site, and so we all have only a few addresses to go around. Right?

Wrong! If you have a gmail account – and who doesn’t? – you effectively have an infinite number of email addresses. And I was surprised how few of the experienced bloggers and content marketers I met on this trip knew this great gmail tip. Hence, this post…

The trick’s really simple. Say your gmail account is yourname@gmail.com. All you have to do is add a plus sign after “yourname” and then any regular email friendly text (no spaces, commas, etc) before the @ sign, and voila! As far as any third party site is concerned, you just created a new, unique, custom email address. It will still be routed to your regular gmail inbox, where you can then build filters to send these inbound emails to different folders if you want to.

For example, phollows+screenscraped@gmail.com is a perfectly valid email address that will reach my gmail inbox, but will by definition be spam (since it will only ever appear in this blog post) and so I can simply route it to junk.

Practically speaking, you can use <yourname>+<sitename>@gmail.com to uniquely track individual subscriptions, purchases, registrations from any web site. With this technique, you can see which sites are selling your email address, for example; or which perhaps have been compromised, because now you can use a unique email address for every site you interact  or register with.

Want to test your email subscription form or popup? <yourname>+<test1>@gmail.com (etc.) will do the job nicely.

With gmail you effectively have an infinite reservoir of unique email addresses you can do almost anything with. It’s pretty neat. Meanwhile, if you’ve some good email tips, we’d love to hear them in the comments.

Feeds, Clicks and DNS Problems

If you or your subscribers have been frustrated trying to get to a FeedBlitz feed (or click through to a link in a FeedBlitz feed) in the last 24 hours or so, the reason is because some third party DNS servers have been returning the wrong results for feeds.feedblitz.com. The net effect is that although FeedBlitz is up and your feeds are being served, some subscribers are being sent to the wrong servers, and getting errors as a result. Update: We’ve routed traffic from the “wrong” server to one of the “right” ones, so even folks affected by this should now get correct data

Here’s the explanation.

DNS, or the Domain Name System, is the thing that translates web host names, like feeds.feedblitz.com, to machine IP addresses, such as, which allows the traffic to get between your computer and the correct server.

Yesterday morning, some DNS services, (notably Google’s public DNS server, which is used by many people, services and organizations), started to return not only inconsistent results, but demonstrably incorrect results.  In short, they redirected traffic to the wrong servers for much of the day.

Now here at FeedBlitz we have an enterprise DNS provider. Misrouting traffic is clearly a major issue and we woke people up yesterday morning to try to (a) correct the situation, and (b) determine what went wrong.  As far as we can tell, our authoritative DNS entries were all fine, but thanks to DNS caching and inconsistent results being returned for much of the day yesterday by Google’s servers, traffic for feeds for some people and services ended up in the wrong place, at a server not expecting nor designed to handle feeds traffic, returning errors.

Despite our best efforts, we couldn’t get Google to return consistent and correct DNS results globally until yesterday afternoon, US eastern. At that point, new DNS lookups for feeds.feedblitz.com will have been successfully sent to the correct servers.

The problem is, however, that DNS lookups are cached – stored temporarily – by the machine making the DNS request. So while Google’s DNS finally got its act together yesterday afternoon, all the queries that were bungled before that were – and are – being cached by the machines that requested them. Those caches are held for a duration known as the TTL – time to live – time. That time may be many hours, and so requests being made to feeds.feedblitz.com now may still being routed to the wrong server, because of incorrect data cached yesterday, if the machine in question, or its upstream DNS provider, got that incorrect data.

We know this is incredibly frustrating for everyone affected, but the cause appears to be downstream from our DNS provider. Our DNS records are correct. As far as we can tell, all major DNS providers are returning the correct results now too. That’s the good news.

While we’re trying to figure out what happened, unfortunately we can’t control downstream DNS caches and third party DNS providers. The ugly truth is, if you’re having problems, unless you’re running your own DNS architecture which you can refresh, all you can do is hang around for your DNS cache’s TTL to expire for the feeds.feedblitz.com record; in other words, hurry up and wait. That stinks, I know.

Still, if you’re on windows, you can run this command from a command prompt to see if you’re affected:

nslookup feeds.feedblitz.com

As I write, you should get four IP addresses back.  If you do, all is well. If not, you have stale and incorrect DNS data. On windows, you can clear your local DNS caches with this command:

ipconfig /flushdns

If you now re-run the nslookup command from further up, you might get the correct results. If not, that means a DNS cache upstream from you is stale and has the incorrect data. At this point, unless you control that upstream DNS server and can fix it, you have to wait for that DNS cache to expire and the correct DNS data to be served.

We here have done all we can to diagnose and address this issue. Our DNS records are correct and are being correctly and consistently returned by downstream servers.

I understand and appreciate the frustration. I hope this helps explain what’s gone on and how little we can control it.



Today I Learned: How to Enable Flash Developers

Not having Flash development experience in-house, we were puzzled recently when we received a support request from a Flash guy wondering why a file we’d never heard of (crossdomain.xml) was giving a 404 file not found error when he requested it. Because it wasn’t there, obviously.

Thankfully, the developer in question was kind enough to throw us a link about why that file was needed for Flash, and a few minutes later we had everything we needed to know. Thanks, Chad!

So if you’re a Flash developer, crossdomain.xml is now available on our servers to permit you to use FeedBlitz-powered RSS feeds in flash apps hosted on your domain. Neat.