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 [hidden]

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.

This is not another engineering seat. We are looking for a founder mindset: someone who has already hit a gap, cared enough to build something for it on their own time or their own budget, and wants a platform to take the next one further than a side project ever goes.

You bring the problem and the conviction. We provide the platform to build it on.

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

What we provide

We can provide the platform for your next build:

Engineering capacity, so your idea does not stay a weekend repo

Access to our customers, enterprises, MSPs, and SOC teams, to validate before you build

Distribution and go to market through the Skedler channel and partner network

Budget and a roadmap we agree up front, with ownership of what you build

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 put an open-source project of your own on GitHub. Send the repo and the star count. This is super important to us, more than a job title. Forks, contributors, and real users count too

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.

To apply

Send your answers to [hidden] all five. Questions 3, 4, and 5 are the ones we weigh most.

What stack did you run, at what scale, and how was it deployed? Numbers where you have them.

Have you put together an open source project on GitHub, and how many stars does it have? Link the repos you started or maintain, and tell us whether you still maintain them.

What projects have you worked on, and what did you build in-house instead of using what already existed? What happened to it afterwards, who maintained it, and is it still running?

What gaps do you observe in open source observability? Rank your top three, one line each. For the first, what did it cost in time, money, or headcount, how many other teams have you seen with the same gap, and what did you try instead?

Why could you not solve this problem? What stopped you on that first gap, time, access, budget, or team buy-in? What would you do differently with engineering capacity behind you?

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