Sourcing an SRE From Public Incident Work: A Teardown

This is a teardown of one real search: turning a US site reliability engineer requisition into a ranked, reachable shortlist by working the operational paper trail instead of the title field. It is for in-house recruiters, sourcers, and talent leaders who keep losing the best reliability engineers to the same drowned-out Boolean strings everyone else runs. Follow along on your own market as you read, and carry your own live counts where I mark that the numbers must be generated fresh.

The problem is specific. The strongest site reliability engineers have thin repos, ignore InMail, and do not look like typical backend candidates. General sourcing guides send you to LinkedIn titles and generic keyword strings, which is exactly where every recruiter competes. This guide instead follows the evidence reliability engineers actually leave in public: postmortem bylines, SREcon and LISA talks, status-page write-ups, and contributions to observability and incident tooling.

Why title search alone fails for site reliability engineers

Title search fails because the best reliability operators are structurally invisible to it, and because the title itself is contaminated with relabelled backend and DevOps engineers. If you only know how to source site reliability engineers by searching the title field, you are fishing the most contested and least differentiated pool available.

Two facts from the GitHub side of the market explain the invisibility. Only 18% of all GitHub activity is public, and 74% of developers are not actively job-hunting. So the operator who ran the pager through a genuine outage and wrote the postmortem may have a quiet profile, a handful of public repos, and no "open to work" flag. Their real trail is the postmortem, not the repo.

The contamination is the other half. Title search inflates with backend and DevOps engineers who relabelled themselves without ever owning a reliability target. The role genuinely does combine a traditional sysadmin or operations engineer role with a developer, which makes the boundary fuzzy and easy to fake in a headline. The paper-trail method beats Boolean precisely here: an incident byline or a peer-reviewed talk is evidence someone did the work, not evidence they typed the words.

What the market actually looks like: pool sizes before you start

Before you write a query, ground yourself in the size of the pool you are fishing. In Refolk's index of professional profiles, 6,509 people in the United States carry the title Site Reliability Engineer, against 1,373 in the United Kingdom. That is the ceiling, and it sets how aggressively you can filter before the funnel collapses.

The US pool is roughly 4.7 times the UK pool for the identical title. The mechanism matters: SRE originated and concentrated in US hyperscalers, so a UK-market search that copies US Boolean strings over-fishes a pool a fifth the size and burns out fast. If you run this method outside the US, expect thinner byline and speaker lists, and lean harder on the conference and postmortem layers to compensate.

Counts come from Refolk's index; share and ratio are derived from those counts. The worked example in this teardown uses the US market so the funnel has room to narrow.

The tooling-signal collapse: why skill filters are not enough

Here is the fork that trips up most reliability searches. If you narrow the US SRE pool by tooling signal, precision rises but volume collapses fast, and skill filters alone will not carry you to a shortlist. This is the single most important number in the guide.

In Refolk's index, only 1,223 of the 6,509 US SREs, about 19%, carry both a Kubernetes and a Prometheus signal. Add or swap to Terraform and you are at 1,036, about 16%. Stack all three and you are into a few hundred people, most of whom every competitor can also find, because these are exactly the strings on the surface of every résumé.

Counts come from Refolk's index; percentages are derived against the 6,509 base. The lesson is not "skip tooling filters". It is that tooling filters must sit alongside a byline or talk layer, not replace it. Filter on skill to raise precision, then reach for the paper trail to recover the volume and the differentiation that skill filters strip out.

The public venues and what each one proves

Reliability engineers leave four kinds of public evidence, and each proves something different about depth. Match the venue to the claim you are trying to make, because a curated-list star and an incident DRI are not the same person.

USENIX SREcon is the primary reliability venue, a gathering of engineers who care deeply about site reliability and working with complex distributed systems at scale. A SREcon talk proves peer-reviewed operational depth, because speakers submit their own proposals. LISA is the older USENIX sysadmin and ops conference, with a shared program-chair lineage, and its program pages are directly searchable for speaker names.

Postmortem collections prove incident authorship. The danluu/post-mortems repository is a public collection of postmortems, sitting at 12.3k stars and 500 forks, and its README links out to Lorin Hochstein's list of major incidents. Company status pages and blogs prove named byline work: Cloudflare consistently generates high-quality public incident writeups, often posting a very detailed postmortem in less than 24 hours after an incident is resolved. Curated lists such as dastergon/awesome-sre and SquadcastHub/awesome-sre-tools prove ecosystem and tooling literacy, which is a supporting signal, not a primary one.

The venue pages are listed as sources; the "proves" column is my synthesis of what each artefact demonstrates, not a vendor claim. Names surface from these venues quickly: John Allspaw coined the blameless-postmortem framing during his tenure at Etsy, Niall Murphy instigated the Site Reliability Engineering book, and Paige Cruz held the pager for InVision, Lightstep, and Weedmaps. Those are the shape of person the paper trail finds that title search never surfaces.

The signals that separate an SRE from a backend engineer

The single differentiator is SLO and error-budget thinking layered on ops tooling. If you want to screen SRE versus backend engineer reliably, look for evidence that the person turned vague reliability goals into precise, measurable targets, because that skill is the one backend and sysadmin résumés cannot borrow.

SLO thinking, defining service level indicators and turning reliability goals into measurable targets, is described as the single most important SRE skill, alongside incident-response depth and writing proper postmortems. Real SREs define and track SLOs, SLIs, and SLAs, manage incident response and lead postmortems, and work heavily with infrastructure-as-code and orchestration tools like Kubernetes, Terraform, Docker, and Ansible. The tooling is table stakes; the reliability ownership is the signal.

Here is what each signal proves, and what it looks like when it lies:

• A numeric error budget or SLO in their own words. Proves they own a reliability target. At 99.9% availability the error budget is 43 minutes per month, and a real SRE can talk in those terms. When it lies: the number is quoted from a vendor blog they merely read.
• A named responder or DRI role in an incident writeup. Proves hands-on incident ownership. When it lies: they left a forum comment on someone else's incident and got indexed as an author.
• Merged PRs to observability or incident tooling. Proves they build, not just consume. When it lies: the repo only mentions Prometheus or Terraform in a README they never touched.
• A reliability or automation mission, not just visibility. Proves scope beyond dashboards. When it lies: they build dashboards for an observability team and never own an availability target.

That query is the byline-and-builder layer collapsed into one ask. Running it in plain English through Refolk does in one step what the manual method does across a GitHub Users search, a commit-history check, and a title cross-reference, and it keeps the SLO-versus-tooling distinction intact instead of drowning in README hits.

The step-by-step search, from first query to ranked shortlist

The procedure below is the whole teardown in order. It carries one US SRE search from persona to reachable shortlist, and it names the fork where sources disagree so you can make the call deliberately. Where I mark that counts must be generated live, run the query yourself and record your own numbers.

On step four, sources disagree on order, and it is a real fork. Some run GitHub-first, harvesting the Users tab and then checking bylines; others run byline-first, starting from postmortems and talks and confirming on GitHub. Byline-first yields higher precision but lower volume. In this worked US run I went byline-first, because the whole point is to escape the contested title pool, and I only dropped into GitHub search to corroborate and to find the repo-thin operators the byline list surfaced.

The wrong turn worth naming: on my first pass I ran a raw site:github.com "postmortem" X-ray and drowned in vendor content. The fix was to require a first-person operational byline before a name entered the list, which I cover in the failure modes below.

For the GitHub queries themselves, stack operators rather than relying on one. The useful ones are language:, location:, followers:, pushed:, repos:, and topic:. A query like language:go location:seattle followers:>=10 repos:>50 returns real people, not repositories, once you switch to the Users tab.

language:go location:seattle followers:50..500 repos:>20 topic:observability
language:python location:"united states" followers:50..500 topic:incident-management
site:github.com "site reliability" inurl:repositories
site:github.com "postmortem" "on-call"

Bound followers with a range like 50..500 rather than chasing the highest counts. Raw keyword search overweights popularity, not fit, and one published workflow recommends followers:50..500 and repos:>20 specifically to avoid over-contacted or inactive profiles.

The funnel: watching the numbers narrow

Here is the shape of the funnel for the US worked example, mixing the grounded title-side counts from Refolk's index with the GitHub-side counts you must generate live. The title side narrows predictably; the byline and talk side you run yourself.

The GitHub-side raw hits, meaning postmortem-repo contributors and SREcon speakers matched to your signals, must be generated live, because exact per-stage GitHub counts are not publicly established. Carry your own numbers at those stages. What is established is the shape of the end: a final human-reviewed, reachable shortlist in a documented single-market run typically lands in the low tens after the tooling and byline filters. That is the correct order of magnitude to plan outreach against, not hundreds.

Low tens of corroborated, reachable operators beats hundreds of unscreened titles every time.

How this goes wrong: the false positives that waste a week

This is the most valuable section, because every failure mode below produces a name that looks right and is wrong. Each one has a false positive and a check. Run the checks before a name earns a rank, not after you have drafted the outreach.

Title search alone. The pool inflates with backend and DevOps engineers who relabelled. The false positive shows no SLO or error-budget evidence anywhere. Check: require a documented SLI, SLO, or postmortem artefact before the name counts.

Vendor blog bylines. "Postmortem" and SRE search results are saturated with incident-management vendor marketing from the likes of incident.io, Chronosphere, and Logit.io. The false positive is an author who writes about incidents but never owned one. Check: confirm a first-person responder or DRI role in a real incident, not a commentary post.

CEO and leadership bylines. A byline is not proportional to hands-on work. Cloudflare's CEO wrote the first version of one incident review, and that is normal for high-profile outages. The false positive is a senior name on a writeup they did not operate. Check: corroborate with commit or tooling evidence before ranking.

Tool user versus builder. A README mention of Prometheus or Terraform is not a contribution. The false positive consumed the tool and never contributed a line. Check: require merged PRs or genuine repo authorship in observability or incident tooling.

Observability engineer mislabel. The tooling overlaps heavily, so the two roles blur. SREs use observability, but their mission is broader: reliability, scalability, and automation. The false positive builds dashboards but does not own a reliability target. Check: confirm the broader reliability and automation mission, not just visibility work.

Masked commit email. Default privacy settings mask emails on recent commits, so the address you scrape may be a dead noreply. The false positive is a bounced first message. Check: search older commits and patches, where the actual push email often appears, plus the profile website.

Popularity bias. Raw keyword search overweights popularity, not fit. Check: bound followers with a range like 50..500 rather than maximising, so you surface working operators instead of the same over-contacted celebrities.

Resolving the contact: the real bottleneck

Identification is not the hard part; reaching the person is. Contact resolution is the bottleneck, because default privacy masks commit emails while tailored outreach lifts reply rates up to 5x, so the effort you spend recovering a real address and referencing their incident or talk pays back more than any volume play.

Pull the author's commit email from history. git log --author="John Doe" --since="2023-01-01" filters commit history to one contributor, and git shortlog --summary --numbered --email --all lists names and emails from commits across the repo. If the user has not anonymised commits, their actual push email appears, often a personal or professional address. When privacy masks recent commits, search older commits and patches, then cross-reference the profile bio and website, and finally match the name against LinkedIn or Refolk to recover a reachable channel. Because Refolk resolves a name and public trail to a person without you touching a paid vendor URL, it collapses the fall-back step that otherwise stalls the funnel.

Verify before you commit: the pre-outreach checklist

Run this checklist before you send a single message. It is the difference between a documented, defensible funnel and a week spent chasing vendor authors and dead noreply addresses.

Keeping the search current

Reliability venues refresh on a schedule, so re-run the harvest against the calendar rather than treating it as a one-time build. The mechanism is simple: new programs and new incidents mean new names, and the people who wrote last quarter's postmortem are the freshest signal you have.

SREcon runs on an annual cadence; SREcon26 Americas is scheduled for March 24 to 26, 2026, in Seattle, and the conference turned 10 in 2024, so there is a decade of program pages to mine and a new one each cycle. Postmortem sources refresh continuously: Cloudflare, for one, experienced a traffic outage on December 5, 2025 lasting about 25 minutes, and posted the writeup fast, as it always does. Re-scan the danluu/post-mortems README and the awesome-sre newsletter links each quarter for new bylines.

Watch the role boundary too, because it is moving. Autonomous tooling like Resolve AI, described as an autonomous SRE platform by OpenTelemetry co-creators targeting an 80% autonomous resolution rate, changes what a human SRE owns, which will change the signals worth requiring a year from now. When it does, re-check the mechanism the same way you would here: what public artefact proves someone did the work, and what does that artefact look like when it lies. Ground the ceiling against Refolk's index each time, and the funnel stays defensible even as the tooling underneath it shifts.