Observability Architect

About Skedler

Skedler is the reporting automation solution for Grafana OSS, Kibana, and Elasticsearch. Enterprises, MSPs, and SOC teams use us to turn monitoring, security, and infrastructure data into scheduled, audit-ready reports.

Reporting was the first gap we found. It is not the only one. This role exists to find the next one, and it may have nothing to do with reporting. Learn more about us at www.skedler.com

Why this role exists

Our engineers build. We are not short of capacity. We are short of the judgement a DevOps or SRE architect builds up from running observability stacks in production, the judgement that says which problem is worth engineering time.

What you will do

• Find the gaps open source observability leaves behind, the ones teams close with scripts, manual effort, or by living with the pain. The deliverable is a written gap inventory, five to eight candidates, each with what it costs, what teams tried instead, and who would pay to remove it
• Own the roadmap for the gap we pick, validate it before we commit engineering time, and work with our engineers on design and architecture
• Adjacent gaps count. If the sharpest one you have seen sits next to observability rather than inside it, bring it

Who we are looking for

• Experience: Minimum 5 years relevant
• You have built internal tooling because the open-source project would not do what you needed. This is the main filter
• You have run Prometheus, Loki, Grafana, OpenTelemetry, Elasticsearch, Kibana, or a comparable stack in production, at a size where you hit scaling limits and had to engineer around them
• You have operated observability for more than one tenant, customer, or business unit
• You have run this in a real deployment model: self-managed Kubernetes, on-prem, air-gapped, or a regulated environment where managed SaaS was not an option
• You have owned or influenced the observability bill and can say where the money and the headcount actually went
• You decided where engineering time went, not just executed someone else's design
• You have validated an idea before building it by talking to users rather than reasoning from first principles
• Plus, not required: contributor or maintainer status in the open-source observability ecosystem or experience applying AI to the stack

Tools: Grafana, Prometheus, OpenTelemetry, AI-based observability, any open-source observability stack

Terms

Contract, converting to a full-time role on a roadmap we agree up front. Full-time hours, remote, work from anywhere.

How to apply

Send your answers to [HIDDEN TEXT]. Answer all five. Question 1 is a short form. Questions 2 to 5 are the ones we read closely.

1. What stack you ran, at what scale, and how it was deployed. Numbers where you have them.

2. What did you build in-house, and why did you build it instead of using what already existed Tell us what happened to it afterwards: who maintained it, what broke, and whether it is still running.

3. Your top three gaps in open-source observability, ranked. One line each. Then expand on the first: what it cost your company in time, money, or headcount, how many other teams you have seen with the same gap, and what alternatives you tried before giving up on them.

4. For that first gap, build versus buy, and who would have signed Which commercial products did you evaluate, and why did you not buy them If a product had closed the gap, who in your company would have signed for it, and what would it have had to cost less than

5. The anti-gap. Name something teams complain about in open-source observability that is not actually worth paying to fix, and say why.

No length limit on questions 2 to 5. Link any public evidence where it exists: repo, talk, blog post, or OSS contribution.