# The Engineering-Signal Reference: What Each Public Artifact Proves

*You can take any public engineering artifact a company emits and state what it proves about the org and the precise way it can mislead.*

- Canonical URL: https://www.refolk.ai/guides/engineering-signal-artifact-reference
- Pillar: Engineering and open source
- Format: Reference
- Published: 2026-09-13
- Last reviewed: 2026-09-13
- Reading time: 18 min
- Keywords: evaluate a company's engineering culture from outside, what public postmortems reveal about a company, signals of engineering maturity, reading a company status page history, how to judge API stability before building

## Key takeaways

- A status page's flawless uptime bar is the weakest signal, not the strongest, because operators can edit historical uptime and post retroactive incidents; only your own RSS or webhook subscription, taken before you need it, is uncheatable.
- A deprecation policy page costs nothing, but serving RFC 9745 and RFC 8594 headers on live traffic requires real engineering, so the header is the load-bearing proof of API stability, not the prose.
- Repeat root cause across postmortems beats any single document's polish: a majority of action items never land because they live in the doc rather than the work tracker.
- In Refolk's index there are 6,572 US Site Reliability Engineers versus 287 US Developer Advocates (22.9x, derived), so an org with DevRel-heavy output and negligible SRE depth is optimizing for the audience, not the system.
- Response-latency and release-frequency signals flip within weeks of one maintainer leaving, so date every signal; the Kubernetes External Secrets Operator took at minimum six months to recover from a single absence.
- A contributor graph of 40 people can still have a Contributor Absence Factor of 1 if one developer wrote 80% of commits, so compute the 50%-of-commits set, not the total.

You are sizing up a company's engineering org from the outside, as a potential employer, vendor, or partner, and you need to know what each public artifact it emits actually tells you and where it lies. This is a lookup document for engineering managers, technical founders, developer-relations leads, and technical sourcers. Jump to the artifact in front of you, read what it proves and how it gets staged, and leave.

Most advice on "reading a company before you commit" is built around interviews and Glassdoor patterns. That misses the richest evidence a company hands you for free: the postmortems, status pages, changelogs, deprecation policies, docs, blog posts, talks, and SDK releases its engineers publish. Each artifact carries a signal, a shelf life, and a specific failure mode. Here is how to read them.

## Which artifacts carry the most weight, and what each proves

Every public artifact proves something narrow and lies in a specific way. The rule that holds across all of them: the cheaper an artifact is to stage, the less it proves, and the load-bearing signals are the ones that require real engineering to produce on live systems.

The table below is the spine of this reference. Each row is one artifact you can look up.

| Artifact | What it proves | How it lies |
| --- | --- | --- |
| Status page history | That incidents were disclosed, if at all | Uptime and incidents are operator-editable; a green bar can mean editing access |
| Postmortem | That a root cause was named and owned | Action items live in the doc, not the tracker, and quietly die |
| Deprecation headers | That API stability is engineered, not promised | A policy page can exist with no RFC headers actually served |
| Engineering blog | That a practice is worth writing about | Prose with no commit, talk, or incident behind it is recruiting marketing |
| OSS/SDK repo | That code is maintained by someone | A big contributor count can hide a Contributor Absence Factor of 1 |
| Deploy cadence | Throughput, one half of delivery health | Frequency climbing while failure rate climbs is a warning, not a win |

Read the two columns together. The signal tells you what to trust when the artifact is honest; the failure column tells you the exact shape of the lie so you can test for it. The rest of this guide expands each row into a check you can run with your hands.

> **Rule:** The header, not the policy, is the proof
>
> Anything a company can publish in prose without touching production is a claim. Weight the artifacts that require real work on live systems: served RFC headers, timestamped incident feeds, and a documented review of prior action items.

## Reading a status page history

A status page proves what a company chose to disclose, not what actually happened. Historical uptime is directly editable by the operator, and retroactive incidents are a standard product feature, so a flawless bar proves editing access, not reliability.

On Atlassian Statuspage, the dominant platform, staff confirm you can edit and correct the historical uptime data for a component, and you can create incidents that occurred in the past if it is necessary to retroactively acknowledge downtime. That cuts both ways: an honest operator backfills a missed incident, and a dishonest one erases one. You cannot tell which from the page alone.

There is one uncheatable move. Subscribe to the RSS or Atom feed and the webhook yourself, before you need them. These are timestamped external records the operator does not control once you hold them. You get a notification whenever the status page creates, updates, or resolves an incident. Later, compare your independent record against the published history. Incidents that never got posted leave no feed trace, but they also earn no downtime credit, so the gap between third-party outage reports and the feed is itself the signal.

One more limitation works in your favor. Once an incident is closed, it is not possible to edit which components were included, and those entries are part of the historical record showing which components were flagged and what notifications went out. An incident scoped to a single minor component can mask broad impact, but the component list on a closed incident is frozen, so read the resolved message and cross-reference outage reports from customers to see whether the scope was honest.

#### The only trustworthy status-page check

1. **Subscribe now** - Attach RSS/Atom and webhook before an incident happens
2. **Snapshot history** - Save the current 90-day and full uptime bars
3. **Wait** - Let real time pass so incidents accumulate in your feed
4. **Compare** - Diff your captured feed against the later published history
5. **Judge** - Gaps and rescoped incidents are the signal, not the green bar

*Independent capture is what turns an editable page into evidence you can trust.*

## Reading changelogs and deprecation policies before you build

The load-bearing deprecation signals are machine-readable and dated; the cosmetic ones are prose. Before you build a core feature on someone's API, the question is not whether they have a policy but whether they serve the headers.

The real proof is RFC 9745, which defines the Deprecation header, and RFC 8594, which defines the Sunset header, served on every response from a deprecated endpoint, plus `deprecated: true` in the OpenAPI spec so generated clients surface the warning automatically. A policy page costs nothing to write; serving those headers on live traffic requires real engineering, which is exactly why the header is load-bearing and the policy is not.

Notice-period norms cluster in a readable range. Common windows run from six to eighteen months, depending on how many active consumers are affected and how complex the migration is. A strong explicit policy gives at least six months minimum between announcement and sunset, and at least twelve months to remove an entire major version. When an endpoint is finally retired, the canonical answer is `410 Gone`, which communicates "was here, now intentionally gone"; some APIs use `404`, which is weaker because it does not distinguish deliberate removal from a typo.

This matters because breaking changes are the top developer grievance: 80% of developers cite them as a major source of frustration. A vendor that serves headers and honors a stated window is telling you, in bytes, that it takes that seriously.

**Deprecation-discipline check**

```
curl -sD - -o /dev/null https://api.example.com/v1/legacy-endpoint | grep -iE 'deprecation|sunset|link'
# Expect: Deprecation: <date> (RFC 9745), Sunset: <date> (RFC 8594), Link: <migration doc>
# Then diff the OpenAPI spec for `deprecated: true` on the same operation.
# Retirement behavior: hit a removed endpoint and confirm 410 Gone, not 404 or 500.
```

*Run against a known-deprecated endpoint. Swap in the real host and path.*

> **Watch out:** A policy without headers is cosmetic
>
> A published deprecation policy that is not backed by Deprecation and Sunset headers on live responses tells you nothing about how a real migration will be handled. Curl the endpoint. If the headers are absent, treat the policy as marketing.

## Reading postmortems for real follow-through

A postmortem proves a root cause was named; it does not prove anything got fixed. The elements that correlate with real follow-through are specific, assigned, time-bound action items, each with an owner, a priority, and a deadline. Action items without owners do not get done, and action items without deadlines get deferred indefinitely.

The single most reliable proof-of-follow-through is a documented review of prior items at the start of the next postmortem. That mechanism makes incompletion visible and forces each open item back into the normal tracker with a named owner and a date. Its absence is the tell. No source publishes an exact completion percentage, and the honest figure is qualitative: a significant share of post-incident-review action items are never completed, and across most organizations the majority of improvement work identified in reviews never reaches implementation.

The documented reason is precise. Action items live in the document rather than in the work tracker, so they are invisible when work is scheduled. Owners and dates on the page look mature and mean nothing if the item never enters the queue that engineering actually pulls from.

So the outside-in test is not the polish of any single postmortem. It is the pattern across several. Cluster root causes over a year. The same root cause recurring across multiple postmortems means action items are not landing, no matter how well each document reads. Postmortems written promptly, within 48 hours after the incident while context is still fresh, are a further quality signal, but recurrence is the one that survives being gamed.

> Repeat root cause across postmortems beats any single document's polish, every time.

## Reading the engineering blog against recruiting marketing

An engineering blog proves a company thinks a topic is worth writing about; whether it proves real practice depends entirely on corroboration. The distinguishing test is specificity and named failure. Developers prioritize real insights over corporate polish, and the authentic tell is public discussion of hard problems and outages.

The pattern of a real engineering culture is concrete: open-source your internal tools, write detailed architectures of your hardest problems, and let your engineers speak at conferences about their specific failures. Cloudflare is the cited model precisely because it writes about its outages and does not hide when it has an incident. Recruiting marketing, by contrast, shows real people doing real work only when it is authentic; otherwise it is stock photography and buzzwords.

The check is mechanical. For every load-bearing claim, find a second independent artifact. A named author who also appears in that company's GitHub commits, a talk recording, or a matching postmortem corroborates the claim. Eloquent prose from a single author with no artifacts behind it is a false positive, so flag it as unverified.

There is a quantitative version of this test using workforce depth. In Refolk's index, 287 people currently hold Developer Advocate or Developer Relations titles in the United States at employers including Stripe, Roblox, Google, and AssemblyAI, against 6,572 US Site Reliability Engineers. An org whose public output is DevRel-heavy but whose SRE depth is negligible is optimizing for the audience, not the system.

**22.9x - More US SREs than US Developer Advocates in Refolk's index (derived)**

6,572 SREs versus 287 DevRel professionals. Heavy DevRel output on thin SRE depth inverts the reliability signal.

| Role | US headcount | SRE-per-role ratio |
| --- | --- | --- |
| Site Reliability Engineer | 6,572 | 1.0x |
| Developer Advocate / Developer Relations | 287 | 22.9x more SREs (derived) |

Headcounts are from Refolk's index of professional profiles; the ratio is derived (6,572 / 287 = 22.9). The reading is not that DevRel is bad, it is that content volume and reliability depth are different things and one can mask the other.

When you need to separate real practitioners from marketing-only DevRel, or confirm that a blog claim has an actual owner, the fastest path is to ask for the people directly rather than reverse-engineer them from post bylines.

I ran this search: `Developer Advocates in the United States who have given conference talks and maintain public GitHub repos` - [see the full result list](https://www.refolk.ai/s/hab3ms0bgz).

*Returns named DevRel professionals with corroborating talk and repo evidence, so you can tell practitioners from copywriters.*

## Reading OSS and SDK maintenance signals

An open-source repo proves code is maintained by someone; the danger is assuming "someone" is a team. The core metrics are defined by CHAOSS, the Linux Foundation project that maintains open-source health metrics: Time to First Response, the gap between an issue or change request opening and the first human reply; Change Request Closure Ratio; Release Frequency; and Contributor Absence Factor, the smallest number of people making 50% of contributions.

Contributor Absence Factor, the renamed bus factor, is the decisive one because raw contributor count lies. A project with 40 contributors can still have a CAF of 1 if one core developer wrote 80% of the commits. Compute the 50%-of-commits contributor set, not the total headcount, or you will mistake fragility for depth.

The documented failure case is exact. When the Kubernetes External Secrets Operator's sole active maintainer took vacation, zero pull requests were merged and 20 new issues opened with no response, and recovery took at minimum six months. One absence, six months of drag. That is why these signals need dates.

#### OSS health signals by shelf life

1. **Time to First Response** - Flips within weeks of one maintainer leaving; re-check within a quarter
2. **Release Frequency** - Also fast-decaying; a stalled cadence shows up in weeks
3. **Contributor Absence Factor** - Structural; shifts over months, not weeks

*The faster a signal flips, the sooner you must re-check it.*

Response-latency and release-frequency signals decay fastest, because a single maintainer's departure flips them within weeks, so re-check within a quarter. CAF is structural and shifts over months. The practical consequence: an undated OSS health reading is nearly worthless. If a repo you depend on is quietly losing its 50%-of-commits set, the earliest external warning is a senior infrastructure engineer leaving the company, which is a rising-CAF alarm you can watch for before the metrics move.

## Cross-checking delivery signals against DORA

Deploy cadence and change-failure signals prove delivery health only when read together; either alone is a false positive. DORA metrics, validated across more than 39,000 survey responses over the program's lifetime, give you published bands to place an org against.

| Signal | Elite / top-tier | Low |
| --- | --- | --- |
| Change failure rate (2025) | 0-2% | 45-60% |
| Deploy cadence | on demand | 1-6 months per change |
| Recovery under 1 hr (share of teams) | 21.3% | n/a |

Change-failure and cadence figures are published DORA benchmarks; the recovery share is from a 2025 practitioner survey. Elite performers deploy on demand with lead time under a day and a change failure rate near 5%, while low performers can take one to six months to ship a single change and sit at 45-60% change failure. The 2025 report set the top-tier change-failure ideal at 0-2%, and only 16.7% of respondents reported a rate that low, so treat that band as rare and demand evidence before assigning it.

Note two moving parts before you cite these. First, elite teams were roughly 19% of respondents in 2024, and the 2025 program retired the four-tier classification in favor of seven team archetypes, so "elite" is a shifting label; describe the mechanism, not the tier name, when you re-check. Second, throughput without stability is a trap. High deploy frequency alone is a false positive, because elite performance requires high throughput and low instability together. Frequency climbing while failure rate also climbs is a warning sign, not a win. Always pair cadence evidence with change-failure evidence.

## The procedure: an outside-in engineering-org assessment

Run the artifacts in an order that captures the perishable evidence first. Baseline the status page before anything else, because you can only get an independent incident record by subscribing before incidents happen.

#### Assess an engineering org from its public artifacts

1. **Inventory the artifacts** - List every public surface: status page, engineering blog, changelog, deprecation policy, docs, GitHub org, SDK repos, conference talks. Done when you have a URL list with a last-updated date per artifact.
2. **Baseline the status page** - Subscribe to the RSS/Atom feed and webhook now so future incidents are captured independently, then pull the 90-day and full uptime history. Done when the subscription is active and you have a saved snapshot.
3. **Score deprecation and versioning discipline** - Call a known-deprecated endpoint and inspect headers for RFC 9745/8594, then diff the OpenAPI spec. Done when you can state the notice window and whether headers are actually served.
4. **Read postmortems for structure** - Check for named root cause, owned and dated action items, and whether a later postmortem references prior items. Done when you have a yes/no per structural element across three or more postmortems.
5. **Corroborate the engineering blog** - For each claimed practice, find a second independent artifact: a commit, a talk, or an incident. Done when each load-bearing claim has one corroborating source or is flagged unverified.
6. **Measure OSS and SDK health** - Compute time-to-first-response, release frequency, and Contributor Absence Factor on the main repos. Done when you have the three numbers plus a dated re-check reminder.
7. **Cross-check against DORA benchmarks** - Map deploy cadence and change-failure signals to the published bands. Done when the org is placed in a band with cited evidence, pairing throughput with stability.

Order note: some SRE-led sources put the postmortem review first, treating culture as the lead signal. Tooling-focused sources lead with changelog and versioning as the most objectively checkable artifact. Both are defensible. I put the status-page baseline first only because its evidence is perishable, then follow whichever order fits your decision.

## How this goes wrong: the false positives

Every artifact has a way of looking mature while proving the opposite. These are the failure modes to test for, each with the check that catches it.

#### Where a signal sits, and what to do

Horizontal axis runs from Cheap to stage to Costly to stage. Vertical axis runs from Proves little to Proves a lot.

| Quadrant | What it means |
| --- | --- |
| Status-page green bar | Ignore until you have your own feed record |
| Served RFC deprecation headers | Trust as strong evidence of API stability |
| Single-author blog claim | Demand a second artifact or flag unverified |
| Repeat root cause across postmortems | Treat as decisive proof follow-through is broken |

*Combine how easy an artifact is to stage with how much it proves to decide how hard to check it.*

- **Staged status page.** A flawless 90-day bar can mean genuine uptime or an operator who edited historical uptime and never posted incidents. Check: your own RSS or webhook subscription captured incidents the page later omits.
- **Owned-but-dead action items.** Named owners and dates look mature, but the items live in the document rather than the work tracker and are invisible when work is scheduled. Check: does a later postmortem reference the status of prior items?
- **Policy without headers.** A published deprecation policy is cosmetic if the endpoints do not serve Deprecation and Sunset headers. Check: curl a deprecated endpoint and read the headers.
- **Repeat root cause.** The same root cause across multiple postmortems means action items are not landing, regardless of each document's polish. Check: cluster root causes across a year.
- **Blog without corroboration.** A claimed practice with no commit, talk, or incident behind it is recruiting marketing. Check: find the second independent source.
- **High-CAF illusion.** A big contributor count hides fragility when one developer wrote most of the code. Check: compute the 50%-of-commits set, not the total.
- **Velocity without stability.** High deploy frequency alone is a false positive; pair cadence with change-failure evidence.
- **Scoped components.** An incident marked as affecting one minor component can mask broad impact, since closed-incident component lists cannot be corrected. Check: read the resolved message and cross-reference third-party outage reports.

## Calibrate by market, and keep the read current

The last correction is geographic. What counts as a mature artifact depends on how deep the local talent pool is, so calibrate the baseline before you judge.

| Market | SRE headcount | Top employer | US multiple |
| --- | --- | --- | --- |
| United States | 6,572 | Google | 1.0x |
| Germany | 597 | Google | 11.0x (derived) |

Headcounts and top employers are from Refolk's index of professional profiles; the multiple is derived (6,572 / 597 = 11.0). With roughly 11 times more SREs in the US than Germany, a German scale-up with a thin postmortem history may reflect a shallower national talent pool rather than weaker practice. Judge a company's artifacts against its market's supply, not against the largest market in the world. When you need to size that supply directly, [Refolk](/) lets you ask for the people in plain English and get the named list back.

Keeping the read current is the other half of the job. The re-check interval is itself a signal. Response-latency and release-frequency flip within weeks of one maintainer leaving; CAF shifts over months; status-page and deprecation baselines should be refreshed whenever you renew a dependency decision. Date every signal you record. Refolk's index makes the workforce checks repeatable, so you can re-run a supply read on a target's reliability org or an SDK's likely maintainers as circumstances change.

#### Before you call the assessment done

- [ ] You subscribed to the status-page feed and webhook before drawing any uptime conclusion.
- [ ] You curled a deprecated endpoint and confirmed whether RFC 9745/8594 headers are actually served.
- [ ] You checked three or more postmortems for owned, dated items and a review of prior items.
- [ ] You clustered root causes across a year and noted any repeats.
- [ ] Every blog claim you relied on has a second independent artifact or is flagged unverified.
- [ ] You computed Contributor Absence Factor from the 50%-of-commits set, not the total contributor count.
- [ ] You paired deploy cadence with change-failure evidence before placing the org in a DORA band.
- [ ] Every recorded signal has a date and a re-check interval matched to how fast it decays.

## Frequently asked questions

### How do I tell an engineering blog from recruiting marketing?

Test for specificity and named failure. Real engineering writing discusses hard problems and outages by name, and its authors also appear in the company's GitHub commits, conference recordings, and postmortems. Recruiting marketing leans on polished prose, single authors, stock photography, and buzzwords with no corroborating artifact behind the claim. If a stated practice has no second independent source, treat it as marketing until proven otherwise.

### Can a company fake its status page uptime history?

Yes. On Atlassian Statuspage an operator can edit and correct historical uptime data for a component and can create incidents that occurred in the past. A flawless 90-day bar therefore proves editing access, not reliability. The one uncheatable move is to subscribe to the RSS or Atom feed and webhook yourself before you need it, then compare your independent timestamped record against what the page later shows.

### What proves an API is actually stable enough to build on?

Machine-readable, dated signals on live traffic. Look for RFC 9745 Deprecation and RFC 8594 Sunset headers served on responses from deprecated endpoints, plus deprecated: true in the OpenAPI spec, and a 410 Gone as the canonical retirement answer. A published policy page with no headers actually served is cosmetic. Notice windows commonly run six to eighteen months, with strong policies giving at least six months minimum and twelve for a whole major version.

### What is Contributor Absence Factor and why does it matter more than contributor count?

Contributor Absence Factor, CHAOSS's renamed bus factor, is the smallest number of people making 50% of contributions. It matters because a project with 40 contributors can still have a CAF of 1 if one developer wrote 80% of the commits. When the Kubernetes External Secrets Operator's sole active maintainer took vacation, zero pull requests merged and 20 issues opened with no response, and recovery took at minimum six months. Compute the 50%-of-commits set, not the total.

### How often should I re-check these signals?

By class. Response-latency and release-frequency signals decay fastest, since one maintainer's departure flips them within weeks, so re-check within a quarter. Contributor Absence Factor is structural and shifts over months. Deprecation headers and status-page behavior should be re-baselined whenever you renew a dependency decision. Date every signal you record, because an undated signal is worse than none.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/engineering-signal-artifact-reference*