- Live system
- Independent project
- Still being built
How Athena works
Athena is a live site about the video game Overwatch. It reads official game data, hero statistics, patch notes, community discussion and creator video metadata, then turns a small part of that into cards that give you a reason to look closer.
The plan goes beyond the homepage.
Where it goes next is deeper pages on this site, more ways to explore what Athena finds, and Ask Athena. The goal is for more of Athena's sources to become useful together, so you can explore beyond the homepage and ask questions using evidence from more than one place. Those parts are still being built or planned.
Here's how those cards get picked today, where their information comes from, and how Athena grew into the system it is now.
Live · Athena homepage01
What Athena is for
If you play Overwatch and want to know what's going on, the information is spread around. Patch notes list what changed. A stats site shows how often each hero (the playable characters) gets picked and how often they win. Reddit shows what players are arguing about. The harder part is working out which of it is worth your attention today.
So Athena picks out a handful of things worth a closer look and puts them on one page. A hero people have suddenly started talking about. A win rate that moved. A map where something unusual is going on. Every card says why it's there.
A card is a starting point, not the whole answer. It gives you enough to see what caught Athena's attention, and what you'd want to ask next.
- OFFICIAL GAME DATA
- PATCH NOTES
- HERO STATISTICS
- COMMUNITY DISCUSSION
- CREATOR VIDEOS
02
Six card families, six questions
Each card family is built around one question: why look at this right now?
There are six because each one looks for a different kind of reason to pay attention. A hero people are arguing about and a hero whose win rate moved are two different questions, so they're two different cards.
- Featured Hero
- Which hero is worth a closer look today?
- Map Atlas
- What's interesting about this map right now?
- Stats SnapshotWALKED THROUGH BELOW ↓
- Where do the stats look unusual?
- Community Pulse
- What are players talking about right now?
- Patch Impact
- What changed in the latest patch that's worth a closer look?
- Creator Intel
- Which recent Overwatch videos are getting attention?
03
Five sources, five different jobs
Each one is good at showing a different kind of thing.
- OFFICIAL GAME DATA
The basic facts about heroes, maps, abilities and perks.
It gives everything else a shared reference point, so Athena knows exactly which hero, map or ability a card is talking about.
- PATCH NOTES
What Blizzard officially changed in an update.
Stats and community discussion can show what happened after those changes.
- HERO STATISTICS
Official pick and win rates, tied to a region, platform and rank.
They help Athena spot unusual patterns and movement in the numbers.
- COMMUNITY DISCUSSION
What players are talking about and arguing about on Reddit.
It helps Athena notice topics that are suddenly getting attention.
- CREATOR VIDEOS
Recent Overwatch videos from a curated set of creators.
They give Athena another view of what's drawing attention in the Overwatch community.
Every card keeps its source attached, so a community opinion doesn't turn into an official fact just because Athena shows it.
So it writes
"players are calling this hero broken"
RATHER THAN"this hero is broken"
It also puts these two side by side
OFFICIAL
a patch change
OBSERVED
a stat movement
Athena shows a patch change next to a stat movement without saying the patch caused it.
04
Qualify, rank, vary
Athena collects far more than it shows, so a large part of each card is deciding what to leave out.
Across the card families, selection follows the same idea: qualify first, rank what survives, then avoid repeating. Each family does it differently.
QUALIFY
Is this worth considering at all?
Qualify. Every card has checks a candidate has to pass before anything else matters. A hero's rates have to move enough to count as a real move, and enough people have to be playing that hero for the comparison to be useful. A community card needs a real post behind it.
EXAMPLE ONLY — NOT ACTUAL COUNTS
THE GATE — ONLY WHAT PASSED CROSSES THIS LINE
RANK
Of what's left, which is strongest?
Rank. Whatever passed gets scored and ordered, and the strongest one is shown. Scoring can't bring back a candidate that failed its checks, so a thin story with a good headline stays out.
Only candidates that passed are ordered here. Anything filtered out at qualification is no longer part of the ranking.
VARY
Don't show the same thing twice.
Vary. A hero shown recently is skipped when there's a reasonable alternative, two map cards never show the same map, and some cards rotate on a schedule.
Each family's rules are written separately, because "interesting" means something different for each one.
- FEATURED HERO
- A hero can qualify because attention is building around them or because their pick and win rates moved. Several sources pointing at the same hero strengthen the case, and a hero shown recently is held back when another hero also qualifies.
- MAP ATLAS
- Maps can stand out for different reasons, such as a hero performing unusually well there or a rise in discussion. Each reason has its own checks, and maps that repeat a story already on the page, or that were shown recently, are held back.
- STATS SNAPSHOT
- Looks for comparisons that don't line up: a hero far from its role average, a large gap between regions or platforms, or a heavily picked hero winning below its role.
- COMMUNITY PULSE
- Scores recent Reddit posts using engagement, subreddit context and a classifier's read of the conversation. The model informs the score rather than choosing the card, and per-hero limits stop one hero taking over.
- PATCH IMPACT
- It works from what Blizzard published and gives more weight to direct, specific changes: hero updates, ability and perk changes, numerical adjustments, and developer notes when they add useful context.
- CREATOR INTEL
- Uses recent videos from a curated set of creators once Athena has their details and knows which parts of the game they cover. It weighs recency, attention, how quickly that attention arrived, comments and official-channel status.
Each family refreshes on a schedule that matches how quickly its source changes.
Follow one card
STATS SNAPSHOTHere's one card, and everything that had to happen for it to show up.
SPECIFIC TO THIS CARD FAMILY
OBSERVE
Overwatch publishes hero performance statistics. Athena reads them through the day.
VALIDATE
It checks the page came back complete.
RECORD
It stores what it found, with the scope attached.
DECIDE
It looks for comparisons that stand out, picks one, and prepares it for the site.
GETTING THE CARD ONTO THE PAGE
PUBLISH
Athena saves the finished card for the homepage.
DISPLAY
The homepage reads that saved card and shows it.
ONE THING WORTH KNOWING
A win rate on its own doesn't mean much. Measured where, on what platform, at what rank, and when? Athena keeps all of that attached to the number, so the card can say exactly what it's comparing.
SPECIFIC TO STATS SNAPSHOT
01OBSERVE
Athena reads the official statistics source several times a day. It doesn't assume it knows what filters exist (platform, mode, region, rank, map), it reads the available options from the source each time.
02VALIDATE
Every read is checked before it's trusted: did the page come back whole, are the numbers plausible, is every hero one Athena recognizes? A bad read is recorded alongside whatever it produced, so a bad day is still explainable months later.
03RECORD
What survives is stored as scoped history: platform, mode, rank, map and time all travel with the number, and older readings are kept rather than overwritten.
04DECIDE
Athena looks for comparisons that stand out: a hero far from its role average, a wide gap between two regions, a hero picked heavily for its role while winning below it. Most candidates aren't used. One is chosen, and a few are kept as the panels that rotate inside the card.
SHARED BY EVERY CARD FAMILY
05PUBLISH
Once the comparison is chosen, Athena saves the finished card for the homepage.
06DISPLAY
The homepage reads that saved card and shows it.
That's this card's chain. The other five families use different checks, because they're looking for different kinds of things.
The last two steps are the ones they all share.
The history
It didn't start as a website
The first version emailed me.
I built it in n8n, a visual automation tool that connects steps together. It pulled Overwatch discussion from Reddit, summarized what mattered, and sent me a weekly digest. That was the whole thing.
Then I kept the data.
Every run was throwing its results away. Storing them instead was a small change, and it's what made everything afterwards possible: once the data was in a database I could ask questions across time.
A status page became the product.
I built a page because I needed to see whether the workflows were still running. Once I started putting useful data on it, like which heroes were winning and which were popular but losing, the page itself started becoming the product.
Then I wanted to ask it questions.
That changed what counted as good data. Most of the work turned out to be nowhere near the question-answering part: it was in getting each source into a shape worth asking about at all. So I went back into how the data was collected in the first place.
What changed as Athena grew
None of this was designed up front. Each change happened because the version before it ran into something.
When the sources changed
Athena reads sources it doesn't control, and they can change without warning. A new hero ships. A new map appears. The statistics page adds a rank tier.
Some source changes don't break the workflow at all. If Athena expects eight rank tiers and Blizzard adds a ninth, nothing has to fail: the collection carries on running and quietly reports on eight. A new hero can arrive and be recognized while the step that stores their portrait fails, so the site shows the hero with a piece missing. Neither case stops the run, so the incomplete result keeps moving: into storage, into the API, onto the homepage.
So newer parts of Athena's data collection increasingly read what each source actually exposes instead of relying on fixed lists I wrote earlier.
A rank tier appeared with no announcement. The statistics source gained a new rank tier without notice. Athena picked it up because it reads the available filter options from the source on every pass instead of working from a fixed list. A fixed list would have carried on working and quietly missed the new tier.
The map list grew mid-day, and the roster keeps growing. A new map showed up between one read and the next, and new heroes have arrived more than once. Each is a content update for players and a data-model event for anyone reading it: a new hero needs artwork, abilities, perks and reference records in place before anything about them can be shown correctly. Athena marks what it doesn't recognize rather than dropping it, so "we don't know this hero yet" is a visible state instead of a silent gap.
When a card looked wrong, I worked backwards from the source. One homepage card was showing something that didn't match reality. I saved the actual upstream page as it appeared that day and traced forward from it until I found where Athena's reading and the source diverged. That only worked because the original reading was still there to compare against.
When one job moved out of n8n
n8n worked well while Athena was mostly chains of automations. As individual jobs got more complicated, keeping all their decision logic inside workflow steps made them harder to test and harder to trace when something went wrong.
One example came from Reddit. Building toward Ask Athena meant Athena had to know what a Reddit discussion was mainly about, not just which hero names appeared somewhere in it. That job is entity detection. The detector started as a few hundred lines of JavaScript inside a single n8n workflow step and grew to several thousand lines as more cases had to be handled.
I tried splitting that logic across more n8n steps, but the hardest decisions were still difficult to follow. So I moved the detector into a dedicated JavaScript service: a separate program that n8n calls when it needs that answer. n8n still handles the surrounding workflow: it collects the Reddit posts, runs a language model that interprets the conversation, and stores the results. The service handles the separate entity-detection decisions.
What it does. Entity detection works out which heroes, maps or abilities a discussion is really about. A thread can be mainly about one hero and mention another only once in a comment. Athena should not treat both as equally important.
What the language model does instead. A language model already reads these threads and interprets the conversation. It works out what kind of thread it is, whether the comments contain a useful answer, and broadly what is being discussed. The detector does a different job. It decides which actual parts of the game the discussion centers on.
Why it got complicated. People don't always use the exact hero name. They use nicknames, abbreviations and ability names, and some hero names are ordinary English words. A hero can also appear once in a side comment without being what the discussion is really about. The detector has to tell those cases apart rather than treating every matching word the same way.
How it grew. The first version was a few hundred lines of JavaScript inside one n8n code step. All of that logic still lived inside the same code step, which eventually grew to several thousand lines of JavaScript.
What I tried first. I tried splitting the detector across around twenty n8n workflow steps. That made the workflow easier to scan, but the hardest decision logic was still difficult to trace when something went wrong.
The service. So I moved the detector into a dedicated JavaScript service. The service separates the work into stages, each stage has one job, and one stage owns the final decision. n8n still collects the posts, runs the language model and stores the results, and calls the service when it needs the entity-detection answer.
IN N8N
ONE CODE STEPThe detector started inside one n8n code step and grew from a few hundred to several thousand lines of JavaScript.
IN THE SERVICE
- STAGE 01
- STAGE 02
- STAGE 03the stage that decides
- STAGE 04
Inside the service, each stage has one job, and one stage makes the final decision.
PROVED
MUST
MATCH
Before the workflow started using the service, I ran the same batches of community posts through both versions and compared the results at each stage.
How I checked the change. I saved outputs from the existing version as test cases, then ran the same inputs through the new service. The results had to match, stage by stage, before I let the workflow depend on it.
Because the new service is split into stages, a wrong result is now easier to trace back to the stage that made the decision.
View the sanitized entity-detection demo on GitHub ↗Rebuilding how Athena collects data
That service move was about one complicated job inside one Reddit workflow. The broader work now is Athena's source pipelines: the parts that fetch information from each external source and turn it into data the rest of the system can use.
Those pipelines are being rebuilt one source at a time as standalone services, rather than keeping the collection logic inside n8n workflow steps. That lets me test and change one source pipeline without changing several at once.
Different source pipelines can use different technologies. A replacement can use Python, or JavaScript or TypeScript with Node.js as the runtime. The plan is for these services to run on Google Cloud Run.
Each pipeline can then have clearer checks on what came back, what changed since the last read, and whether the result is complete and correct enough for Athena to use. Hero Stats is first.
Because the existing n8n workflows are still what collect the live data for the site, and they didn't all grow the same way. Each one accumulated its own parsing details, its own handling for updates and duplicates, its own retries and workarounds, and its own assumptions about what comes out the other end. The sources behind them don't fail in the same ways either.
Replacing several source pipelines at once would multiply the number of things changing together and make problems much harder to isolate. Going one source at a time means I can work out what that source exposes now, what the existing workflow actually does with it, and what depends on the result, then test the replacement against the current behavior before anything cuts over.
Moving the collection work into standalone services does not stop an external source from changing, but it does change how clearly Athena can see it happen: clearer rules about what a source has to return, checks and tests on what came back, a record of what was read, and failures that show up instead of moving quietly into the rest of Athena.
That matters more as Athena moves toward answering questions. A missing image on a card is easy to notice, but stale or incomplete data can still produce an answer that sounds convincing. When I started working toward Ask Athena, I expected most of the difficulty to be in finding the right stored information and using it to answer a question. In practice, much of the work comes before that: collecting, checking and storing each source well enough that it is worth using later.
In progress
No source pipeline has switched over yet.
The existing n8n source workflows still feed the site today.
What's live, what isn't
Live
- The Athena homepage. All six card families are live and use real data from Athena's current source workflows.
Being built
- Ask Athena. The groundwork is being built and tested. Public chat is not live yet.
- Rebuilt source pipelines. Athena's older n8n collection workflows are being replaced one source at a time with standalone services and stronger validation. Hero Stats is first; none has replaced its live workflow yet.
Later
- More pages on the Athena website. Deeper pages for heroes, maps, patches, community and statistics. Planned, not started.
- Deeper video understanding. Creator Intel currently works from video metadata and engagement. Later work would use transcripts and content analysis so Athena can understand which parts of the game a video is actually about.
How I work on Athena
I use AI tools heavily while working on Athena, but I don't treat their output as the answer. I decide what the system should do, test what comes back, investigate why something failed, and decide whether a change is actually good enough to keep.
My background is in technical support, and that shapes how I approach the project: start from what actually happened, trace a problem through the systems involved, and verify the fix rather than assuming it worked.
What Athena is built with
These are technologies I've used while building and running Athena.
- Collecting and processing data
- n8n · Python · JavaScript · Node.js
- Storing it
- PostgreSQL / Cloud SQL
- Serving it
- FastAPI · Google Cloud Run · Cloud Storage · HTTP / JSON APIs
- The website
- Next.js · TypeScript · React
- How I work
- Git / GitHub · AI development tools
Athena is an independent project, built and run by one person. It's live today and still growing.