Overview

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.

Responsibilities

• 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
• 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

Qualifications

• 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
• 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?