GitHub Username Lookup: A Practical Guide

What "looking up a GitHub user" actually means

The github.com profile page has been the de-facto answer for a decade: a navbar, a sidebar, a pinned-repo grid, a contribution graph, and a busy footer. It's great when you're on GitHub doing GitHub work. It's overkill when you're on Slack and someone asks "who is this person."

A username lookup is just the public profile minus everything else. Avatar, bio, location, blog link, follower count, repo count, joined date. That's the answer to "who is this." github.dawg.bot is built around exactly that flow.

How github.dawg.bot resolves a username

When you visit github.dawg.bot/torvalds:

1. The catch-all route asks the Dawg API to resolve torvalds against the github platform.
2. The API hits GET https://api.github.com/users/torvalds if the cached snapshot is stale.
3. The raw JSON response is stored as a ProviderSnapshot and normalized into a PlatformAccount row.
4. The lens fetches the normalized profile and renders it.

You don't see any of that. You see a clean profile page in maybe 250ms with the data GitHub itself returned.

If the username doesn't resolve, the page shows a not-found card with the exact reason (github_account_not_found, github_rate_limited_or_forbidden, etc.) and a link to github.com/<user> so you can verify directly.

What's actually on the page

• Avatar and display name
• The handle in @user form
• Bio if the user has one
• Public repo count, followers, following, gists
• Joined date and the most recent profile update
• Company, location, blog URL, X/Twitter handle when public
• A direct link to the canonical github.com URL

For repository previews (github.dawg.bot/owner/repo), you also get stars, forks, watchers, default branch, license, topics, and the homepage URL when set.

Why a separate domain

The Dawg architecture gives every platform its own lens domain. Discord lives at discord.dog, Minecraft at mc.dog, Steam at steam.dog. They all read from one identity graph but render with the visual conventions of that platform.

Concretely, that means:

• The same profile can show up on multiple lenses if cross-platform connections exist. A Discord profile linking a GitHub username creates a ConnectionEdge that surfaces on both lenses.
• Each domain gets its own SEO surface, sitemap, and tool pages, instead of cramming everything into one product.
• A future bot at the central account portal (dawg.bot) can run /lookup torvalds and pick the right lens automatically based on what the input shape looks like.

When to use the github.com URL instead

Use github.com when you actually need GitHub: starring a repo, opening a PR, reading code, filing an issue, anything that requires you to be signed in. github.dawg.bot is for the read-only sharing case where the recipient might not have a GitHub account or might not want to load the full app.

The two URLs always coexist. Every github.dawg.bot page links straight to github.com so nothing's hidden, nothing's mediated, you're always one click from the canonical source.

What's coming

The current lens is the minimum that's useful. Roadmap items, in rough order:

• Cross-lens connection rendering (showing the linked Discord, Steam, etc. accounts on a profile)
• A snapshot history view for claimed accounts via the dawg.bot dashboard
• Org pages with member counts and pinned repos
• A repo-stats tool page with a paste-a-URL form

If you want any of those sooner, the repo's open to PRs.