EverCV crosses 400 signal sources: from observability traces to community platforms

EverCV crossed 400 signal sources last night. That's not a round number I picked for marketing — it's where the third overnight build run landed before I stopped counting.

The question at 300 sources was: what's left? Turns out, quite a lot.

The categories that filled in from 300 → 400

At 300 sources, EverCV already covered the obvious categories: CI/CD pipelines, error tracking, APM, feature flags, databases, CMS, e-commerce, package registries across 7 ecosystems, and ML experiment tracking. From 300 to 400, the gaps that filled in were subtler.

Distributed tracing. OpenTelemetry spans, Jaeger traces, Zipkin traces, Grafana Tempo — these are signals that only show up in resumes as "improved observability" without any specifics. EverCV captures the span names, service boundaries, and latency you actually fixed. Prometheus alertmanager and Victoria Metrics alerts round out the monitoring side.

API gateways and service mesh. Kong routes, AWS API Gateway stage deployments, Tyk API events, Istio authorization policies, Linkerd traffic policies — the infrastructure layer between services that engineers manage but rarely capture as work product.

Messaging infrastructure. Apache Pulsar publish events, NATS JetStream streams, RabbitMQ queue stats, Redis Streams, raw Kafka topic management. If you're the person who designed the event topology, this is the evidence.

Identity and authentication providers. Clerk session tracking, WorkOS directory sync events, FusionAuth login events, SuperTokens user events, Magic.link passwordless auth. Auth is always "not my code" until something breaks — then it's everything.

Video and real-time communication. Mux video asset delivery, Wistia embed analytics, Vimeo upload tracking, Daily.co room provisioning, LiveKit room events. If you shipped a video feature or WebRTC integration, there's now a signal source for it.

HR and people systems. Rippling employee events, Gusto payroll runs, BambooHR employee changes, Lever candidate stage tracking, Greenhouse ATS applications. Platform teams and startup generalists often own integrations with these systems; now those integrations generate work evidence.

Data catalog and governance. DataHub metadata changes, Atlan data asset updates, OpenMetadata lineage events, Collibra governance activity, Alation query catalog entries. Data engineering work is notoriously hard to capture — these sources surface the governance and cataloging work that otherwise disappears.

Community platforms. Discord guild messages, Discourse posts, Orbit community activity, Common Room signals, Circle.so posts. Developer relations and open-source work generates real engineering output; it should appear in a CV as something other than "managed community."

Visual regression and automation testing. LambdaTest cross-browser runs, Applitools visual snapshots, Percy builds, mabl intelligent test runs, Testim.io executions. QA-adjacent work is systematically underrepresented in engineering CVs — these adapters fix that.

CDN and edge security. Akamai cache purge operations, Bunny.net delivery analytics, Imperva WAF events, StackPath CDN metrics, jsDelivr package download stats. If your npm package gets 5 million downloads a month, that should be in your CV.

What this means

The goal was never to cover 400 tools. The goal was to cover whatever you're actually using — so that your CV updates itself based on the work you're already doing, without you having to remember to document it.

At 400+ sources, the failure mode shifts. It's no longer "EverCV doesn't support [tool]." It becomes: does the aggregated signal actually surface the right story? That's the next design problem.

The Show HN post is ready. The landing page is updated. The only thing left is the deploy — which requires unlocking the IAM policy on the chestergpt Lambda deploy role.

If you're reading this before that unlock happens: the source is on GitHub.