Right now the only urls that should be used are www and web2. If you use any other address or IP address your connection will definitely fail. Issues with www are related to dns problems.

Any updates from the administrators on this?

The site has been now down more or less for the last five days.

Is there something wrong with the platform that the FlyerTalk uses? I have not experienced as severe problems with other message boards that I actively follow that are at least if not more popular than FlyerTalk.

Timing out or so slowwwwwww its glacial today.

www.flyertalk.com seems to be sailing along as of 11:50am Pacific.

EDIT - Disregard the above. The site 404'd during the post. :)

Both www.flyertalk.com and web2.flyertalk.com seem to load with no problems and quite quickly, and you can navigate for about 2-3 minutes, then the sites 404.

Close browser. Wait a few minutes. Repeat above.

I have cleared my cache and temp internet files, even rebooted, but still no dice. Same issue as above.

(Now let's see if I can post this)

Update from TX
 

The site has remained "iffy" the past few days, as others have noted. However, before this morning it has always been accessible. This morning at home (around 4.30am CST) I was able to get to FT on the third try (and when I did get through, it was running uber fast) yet it would often flake out after a few minutes.

At school today I have experienced similar problems (when it works, usually after a couple of tries, it works great - than it starts to time out.)

Thank you guys for checking into this ^^ ... For I need my FT fix even more than the coffee fix :eek:

Anyone know what the problem is?

It's 1:55pm PST and I'm still having the issues as listed above.

I heard the doohicky on the new flux capacitor is broken.

No wonder I'm in 1987!

need an inection of 1.21 Jigawatts

Well, I've never had a problem pinging the various urls, nor the IP address directly, so it's not a hardware or DNS issue. Nor does it look like a disk or other hardware failure that required a restore from backups - that would have been owned up to and we'd be beyond that problem by now. I'd guess someone's learning the hard way about not making untested changes to a running system without testing said changes thoroughly before deploying them on the operational system.

I've had to fix situations where a simple version upgrade for a database caused the app running against the database to stop using any indices and have to scan entire database tables for data because of the way the new version of the database subtly changed index usage in a way the (multi-million lines of code) applications couldn't handle. Of course, when the DBAs and testers ran the apps against their test database with a few tens of rows in each table, it seemed to work fine. But when they upgraded the operational database, with its millions and millions of rows of data in each table, performance of the applications ground to a screeching halt. Of course, in typical government contractor fashion, the DBAs and the testers all got awards for a "successful" upgrade. :p

In other words, I'll bet somebody broke it bad and can't figure out how to fix it...

Ditto

BTW congrats airbus320 on 10,000 posts.

Exact same problems......SSSSSLLLLLLLLLLLLOOOOOOOOOOOOOWWWWWW WWWWWW!!!!!