A 30-minute working session with an ex-FAANG SRE. Not a sales call.
You bring your stack. We bring someone who has run a 24×7 incident rotation at a hyperscaler. Together we wire CoreWatch against a real workload and see what surfaces — no slideware, no scripted demo, no discovery meeting before the discovery meeting.
Solutions engineers run every call. The person you book is the person you talk to — no SDR handoff, no “let me loop in an architect.”
What actually happens on the call.
A literal transcript of the working session, in the order it runs. No “alignment chat.” No “next steps.” A real engineer opening your dashboards before minute 7.
-
01
Minutes 0–5 — Stack read-out
Your SE has already read the four context fields you submitted. You confirm what is on top — Datadog, New Relic, Grafana, Honeycomb, none, all four — and what you actually want CoreWatch to replace first. If the stack is fine and you’re here for a sanity check, we say so in minute three.
~5 min -
02
Minutes 5–15 — Live wire-up
The SE opens a CoreWatch tenant, drops the OpenTelemetry collector config in a shared terminal pane, and ships traces from one of your staging services. You watch the spans land in real time. No pre-canned demo data — it is your code, your latency, your error rates.
~10 min -
03
Minutes 15–25 — One real question
Bring one production question you actually have right now — a flaky checkout endpoint, a noisy K8s node, a memory regression from last Tuesday’s deploy. We pull the data together and answer it live. If we can’t, we’ll tell you which query would answer it and where to look.
~10 min -
04
Minutes 25–30 — Numbers, not next steps
The SE pulls up the pricing model against your stated cluster size and span volume. You leave the call with a quote and an ingest cost projection. If the math doesn’t work, we’ll say so before you waste an evaluation cycle.
~5 min
Tell us about your stack so the SE arrives briefed.
Every field on the booking form exists for one reason: to make the 30 minutes more useful. We don’t sell your inputs, we don’t enrich them against a third-party database, and the SE reads them before the call starts — not during it.
-
i.
Engineering team size
So the SE knows whether to talk about per-host economics or per-cluster rollouts — the math changes at ~25 engineers.
-
ii.
Current observability stack
A dropdown of the tools you actually pay for — Datadog, New Relic, Dynatrace, Grafana Cloud, Honeycomb, self-hosted, or none. The SE arrives with a migration sketch already drawn.
-
iii.
Kubernetes node count
The cheapest variable for sizing ingest. If you don’t run K8s in production, leave it blank — we have ECS, Nomad, and bare-metal customers too.
-
iv.
Primary use case
Pick the one that hurts most right now: incident response, cost reduction, OpenTelemetry migration, SLO adoption, or replacing a sunsetting vendor.
None of these fields are used to gate the form behind a BANT filter. If you want to talk to an engineer, you can talk to an engineer.
Brief the SE. Pick a slot.
Eight fields. Most take a click. We confirm within one business day with a calendar invite from a real engineer’s calendar — no Calendly redirect, no “advisor.”
Demo slots are a scarce resource right now.
Seven solutions engineers, calendar opened roughly two weeks out. The honest read: if you want to talk before your next incident, book now. If you want to wait until the queue shortens, the queue shortens every Friday — but the people who waited six weeks to look at observability tools are usually the people whose dashboards nobody reads.