Kudos Bot, 502 Errors, and Other AO3 Technical Stories

This article explores a few fascinating technical anecdotes from AO3’s history.

1. Kudos Bot: the sudden rise of guest kudos

Kudos are AO3’s lightest form of feedback, basically meaning “I liked this.” Under normal conditions, a logged-in user can leave kudos on a work once, and guest kudos are also limited.

Around October 2021, many authors began noticing sudden waves of guest kudos. Some works had not updated in a long time and were not on a hot fandom front page, but still received dozens, hundreds, or even more guest kudos in a short period. Some users also noticed that the rise in kudos did not match the rise in hits. People began calling it the Kudos Bot¹.

The strange part was that it did not look like ordinary readership or a normal publicity spike. Fanlore’s summary notes that the cause was not confirmed. Guesses included misbehaving crawlers, pranks, or other bot activity. One effective temporary workaround was to lock works to registered users only; once guests could not access the work, they could not leave guest kudos either¹.

2. 502 errors: AO3 was crowded early

AO3’s 502 errors are not new. As early as 2011, OTW published an explanation of why AO3 often showed a “sad 502 page”: traffic had grown too quickly for the servers to keep up. That post mentioned that on September 25, 2011, AO3 had 105,000 visits, 46,000 unique visitors, and 575,000 page views, and that this had already become a fairly ordinary day².

In 2012, AO3 published another performance note. By then, AO3 averaged more than 1.5 million page views per day, and traffic was concentrated in the evening peak after users in Europe and the Americas got home from school or work. The explanation was straightforward: too many requests, not enough processing capacity, and users would see 502 errors³.

There is a very AO3 example from early 2012: “Rush hour on the AO3!” explained a New Year traffic spike. On January 2, 2012, AO3 had 182,958 visits and 1,066,216 page views. The same announcement noted that Yuletide and other challenge events had brought in many new works⁴.

So a 502 error does not always mean the site is broken in some mysterious way. Often it is a plain capacity problem: many people reading, posting, refreshing, and checking updates at the same time.

3. Elasticsearch: AO3 search and tags are not easy

AO3’s 502 errors are not only about “too much traffic.” In 2017, AO3 explained another specific problem: when users post or edit works, AO3 needs to update the usage count for every tag on those works. Popular tags are used by many works at the same time, and those records can be locked while they are being updated. When the database gets busy, posting, editing, or even the whole site can slow down; in severe cases, users may see 502 errors⁵.

This says a lot about why AO3’s tag system is hard to maintain. To readers, tags are just a few words on a page. To the system, they are constantly changing data behind search, filters, statistics, autocomplete, and tag wrangling.

In 2018, AO3 made a major search upgrade, moving Elasticsearch from 0.90 to 6.2. The update brought features many users now take for granted: excluding tags, filtering for crossovers, completion status, updated date, word count ranges, and more⁶⁷. AO3 also said the old bookmark code put pressure on the servers when large tags changed through wrangling, while Elasticsearch 6 could better handle more than 74 million bookmarks⁷.

So AO3’s “search” is not just a simple search box. Behind it are millions of works, tens of millions of bookmarks, countless user-created tags, and canonical tag relationships maintained by volunteers over time. When you click a filter, the system is really taking you through a complex fan-made classification network.

4. The 2023 DDoS attack: from handling it alone to Cloudflare

In July 2023, AO3 was hit by a large DDoS attack. AO3’s official announcement said the archive was mostly unavailable from about 12:00 UTC on July 10 to 16:00 UTC on July 11. The same announcement said no archive data had been compromised and users did not need to worry about passwords or private information being breached⁸.

AO3_Systems later published a useful behind-the-scenes report. According to its timeline, AO3 began seeing unusual traffic around 11:48 UTC on July 10. A normal peak was about 150,000 requests per minute; during the attack, spikes exceeded 1,000,000 requests per minute and reached 1,500,000. At 00:21 UTC on July 11, AO3’s data center notified the team that the attack had exceeded 1.2 Tbps, roughly 600 times the site’s bandwidth capacity at the time⁹.

At first, Systems volunteers tried to defend the site themselves: maintenance mode, front-end handling, firewall blocks for abused pages, and temporary rate limits. But the attack kept changing targets and eventually exceeded what AO3’s own network and servers could handle. On July 11, the team began moving behind Cloudflare and received stronger protection through Project Galileo. Around 15:42 UTC that day, AO3 was fully accessible again⁹.

Cloudflare’s later case study says the attack took AO3 offline for a total of 28 hours and notes that all OTW projects are online projects; when they are offline, they cannot carry out their mission¹⁰.

5. Cloudflare solved one problem and created others

After Cloudflare, AO3 was no longer completely exposed to hostile traffic. The problem is that protection also changes user experience.

AO3’s announcement said the team temporarily enabled Cloudflare’s Under Attack mode. Users might see CAPTCHA checks. AO3 also acknowledged that some browsers and older devices could not access the site at the time. These measures were temporary and would be reassessed after the attack stopped⁸.

The Systems report also says attacks continued in August. Most were blocked by Cloudflare without visible impact, but August 30 and 31 still saw brief issues. One automatic rule caused some collateral damage: users saw Cloudflare’s default “Sorry, you have been blocked” page. AO3 later replaced it with a gentler custom message⁹.

That is the practical side of security: it can block attacks, but it can also catch ordinary users, especially those on older devices or complicated networks.

For Chinese-speaking users, this kind of change can be amplified through mirror sites. Many people access AO3 through mirrors, and nightalk is one of the names often mentioned. Mirrors are not official AO3 services. They usually depend on the main site and their own proxy chain. If AO3 enters Cloudflare verification or temporarily changes security rules, users may not be able to open the mirror.

6. Users turn outages into fandom events

AO3 users usually do not wait quietly when the site is down.

During the 2023 DDoS attack, AO3’s official announcement specifically mentioned support messages and cute gifs from users⁸. TechCrunch later wrote about a funny phenomenon: after AO3 came back, people were still chatting in Downdetector comments and even writing AO3 and Downdetector as a personified relationship, creating a temporary “Downdetector fandom”¹¹. If you want to see whether many users are currently reporting AO3 problems, you can also check AO3’s Downdetector status page.

A site outage is annoying, of course. But users’ first reaction is often not only to complain about the servers. They post images under status updates, write jokes in comment sections, tell each other whether the site is loading, and turn a technical problem into a community event. Then the event quickly grows its own memes and jokes.

Conclusion: A Living Record of a Resilient Community

Taken together, AO3’s technical history is not exactly perfect. It has had guest kudos bots that made authors doubt what they were seeing, repeated early 502 errors caused by traffic growth, infrastructure upgrades driven by search and tag pressure, and DDoS attacks that forced an emergency move behind Cloudflare.

But that also shows AO3 is not a static archive. User growth pushes it to expand capacity. Search and tag pressure pushes it to upgrade infrastructure. Attacks push it to change security strategy. Bots force it to rethink guest interaction.

So AO3’s “technical stories” are not only bugs and outages. They are also the operating record left behind by a large fan community running in the real internet.