PeoplePractitioner6 min read27 October 2026

How do you write an observability job description?

The structure of a job description that attracts the right observability and reliability profiles, common mistakes, what the law requires and two templates ready to adapt: observability engineer and SRE with on-call.

For: team managers · executives and CIOsPrerequisites: Having chosen the profile you are looking for; [Which profiles should you hire?](/en/people/observability-roles/) helps.

Reading mode

Illustrative scenario. Two ads for the same SRE role. The first lists Kubernetes, Terraform, Prometheus, Grafana, Datadog, Python, Go, Ansible and “an excellent ability to work under pressure”. The second says: “The payment service had twelve major incidents last year. Your mission: halve that number within a year, with the product team. On-call one week in six, compensated.” The second gets fewer applications, but almost all of them are relevant.

This page follows Which profiles should you hire?. It gives a structure, the mistakes to avoid and two templates. The job description generator produces a first version tailored to your context.

The structure that works

A job description answers seven questions, in this order.

Why the role exists. The problem to solve, in two or three sentences, with a figure if you have one.
What the person will have changed in a year. Two or three concrete results. This is what lets the candidate picture the job and lets you assess the probation period.
The day-to-day. How time splits: building, incident response, supporting teams, meetings.
The environment. Team size, reporting line, the tools in place and the ones the person will be able to choose.
On-call. If there is any: frequency, rotation size, compensation, volume of night alerts. If there is none, say so.
What is essential and what can be learned. Two separate lists, the first one short.
Conditions. Salary range, location, remote work, the hiring process.

Common mistakes

Mistake	What it produces	What to write instead
a list of tools as the job description	candidates who know the tools but not the job	the problem to solve, then the tools in place in one line
on-call left unsaid	a resignation at the end of probation	frequency, rotation size, compensation
fifteen essential requirements	applicants who rule themselves out	three or four essentials, the rest under “can be learned on the job”
“under pressure”, “demanding environment”	the signal of an understaffed team	the actual workload, with figures
a fashionable title that does not match the work	the wrong profile, disappointed after three months	the title of the profile that matches the problem
a required number of years of experience	excluding competent people with unusual paths	the expected level of responsibility (design for a team, set the rules for several)
no salary range	interviews that fail at the last moment	a range, mandatory soon anyway (see below)

What the law requires

The applicable law depends on the country. In France, a few rules are worth knowing; your HR team or lawyer remains the reference.

Criteria must relate to the job. The Labour Code forbids rejecting a candidate on discriminatory grounds (article L1132-1) and requires the information asked of a candidate to have a direct link with the job offered (article L1221-6, on Légifrance). “Young, dynamic team” or an implicit age limit have no place in a job description.
The title is neutral. A masculine-only title is to be avoided in French; in English, gender-neutral titles are the norm.
Pay is disclosed. Directive (EU) 2023/970 on pay transparency provides that candidates receive the starting pay or its range before the interview; it also forbids asking about their current pay. Member States had to transpose it by 7 June 2026 at the latest: check with HR where the national text that applies to you stands.
On-call is regulated. In France, it gives the right to compensation in money or in time off (article L3121-9 of the Labour Code). The job description can say so plainly.

Template 1: observability engineer, mid-level

This template is an example to adapt: the figures and the context are fictitious.

Observability engineer (mid-level)

Why the role exists. Our forty developers deploy about thirty services. When a request is slow, it takes on average half a day to find the service at fault: traces are missing and each team has its own dashboards.

In a year, you will have:

instrumented the critical services with OpenTelemetry and set up a shared collection pipeline;

written the naming conventions and reference dashboards the teams reuse;

trained each team to read a trace, to the point that it diagnoses its own slowdowns.

Your day-to-day. About half of the time building (collection, storage, conventions), a third supporting the teams (pairing, workshops, instrumentation reviews), the rest on support and continuous improvement.

The environment. Reporting to the head of the platform team (four people). Java and Go services on Kubernetes, metrics in Prometheus, logs in a tool to be replaced: choosing where traces and logs are stored will be one of your first projects.

On-call. No on-call on this role; product teams hold on-call for their own services.

Essential: having instrumented at least one service in production; reading a distributed trace and explaining what it shows; explaining a technical choice to developers.

Can be learned on the job: the OpenTelemetry Collector in depth, our internal tools, Go if you come from Java (or the other way round).

Conditions. Salary range stated, location, remote work. Process: a 30-minute call, a one-hour diagnosis exercise with two team members, an interview with the manager. Answer within ten days.

Template 2: SRE with on-call, mid-level

SRE, site reliability engineer (mid-level)

Why the role exists. The payment service had twelve major incidents last year, three of them longer than two hours. Nobody owns its reliability end to end today.

In a year, you will have:

defined with product the reliability objectives (SLOs) of payments and the error budget that follows;

halved the number of major incidents or their duration;

set up blameless post-mortems whose actions are followed through.

Your day-to-day. About half of the time on engineering (automation, hardening, alerts), a quarter on on-call and incidents, a quarter with the product team (design reviews, SLOs, prioritization).

The environment. Reporting to the head of reliability. You work with the payment team (eight developers) and with the platform team, which provides the observability tooling.

On-call. One week in six, with a designated second level. On average fewer than one call per on-call night over the last three months. Financial compensation and recovery the day after a night of intervention.

Essential: having been on call in production; coordinating an incident and writing a post-mortem; writing an SLO and the alert that goes with it.

Can be learned on the job: our domain (payments), our tools, Terraform if you come from another infrastructure tool.

Conditions. Salary range stated, location, remote work. Process: a 30-minute call, a one-hour incident simulation, an interview with the manager and a member of the product team. Answer within ten days.

Reread before publishing

Before publishing, have the description reread by someone already in a similar role, in your team or elsewhere. Ask three questions: would you apply? What would make you hesitate? What is missing to understand the role? Their answers are worth more than any grid.

Going further

Which profiles should you hire for observability?: the five profiles and skills by level.
How do you run the interview?: the next step of hiring.
The job description generator: a first version tailored to your context, with the interview plan.
Sustainable on-call: the figures to know before writing the “on-call” line.