How to get a DevOps conference talk accepted

Most DevOps conferences choose their programme the same way: a call for papers (CFP) opens a few months before the event, people submit a title and an abstract, and a committee of volunteers reads and scores every submission. Nobody on that committee knows you, and most of them will spend a minute or two on your abstract before moving on. Getting accepted is less about being known and more about making that minute count.

This guide is about that minute. The examples come from calls listed on this site in October 2026; the open CFPs page has the current list, sorted by deadline.

Start from a story only you can tell

Accepted talks almost always come from something the speaker did. “An introduction to observability” competes with hundreds of similar submissions. “How we cut our alert volume after moving three hundred services to OpenTelemetry” is a talk only one team can give.

Before you write anything, answer three questions:

1. What did you do that other teams are about to try?
2. What went wrong, and what would you do differently?
3. What can someone in the audience change on Monday because of your talk?

If you cannot answer the second question, you probably do not have a talk yet. Reliability events in particular want the honest version. The call for SREcon27 Americas asks for talks on the systems and the business context SREs work in, and its call for participation requires speakers to submit their own proposals and confirm the content is mainly their own writing.

Read the call, then last year’s programme

Every CFP page says what the organizers want, and many say what they will reject. A few examples from current calls:

• DevOpsDays Geneva wants no commercial content and turns down vendor pitches, although people who work for vendors may submit.
• ContainerDays London rules out sales pitches and closed-source products, and asks for one of three lengths: lightning talk, 30-minute talk or 60-minute workshop.
• KCD Texas wants end-user stories and asks vendor speakers to share lessons rather than pitches.
• DevOpsDays Zurich accepts up to two submissions per person.

Ignoring instructions like these is the fastest way to be rejected unread. Then look at what was accepted last time. Most conferences publish their previous schedule, and many publish recordings. You will see the depth they expect, how long talks run, and which subjects are already well covered.

Pick the stage that fits your first talk

The large events are the hardest to get into. Several smaller formats are built for new speakers, and they are a better place to start:

• Community events with coaching. DevOpsDays Atlanta and DevOpsDays Raleigh both say they offer coaching to first-time speakers, KCD Texas pairs them with a mentor, and Cloud Native Summit Munich encourages first-time speakers. DevOpsDays events also take five-minute Ignite talks, a short format that is easier to fill well.
• Online events. The Conf42 series runs free online days with pre-recorded talks, so there is no travel and no stage fright on the day. Conf42 DevOps takes submissions on cfp.ninja until 24 December 2026, and other Conf42 topics run calls well into 2027.
• The day after a rejection. Cloud Native Rejekts exists for good talks that did not make KubeCon. Its call opens on 7 December 2026, the day KubeCon Europe acceptances are due, and closes on 3 January 2027.
• Co-located events. Large conferences such as KubeCon + CloudNativeCon Europe run co-located days with their own calls and a narrower audience. For Barcelona 2027 the main call closed on 11 October 2026 and the co-located call on 18 October 2026.

Write the title last, and make it specific

A good title tells the reviewer what the talk is about and who it is for. Clever puns read well to you and confuse a tired reviewer at the end of a long scoring session. “Taming the Beast” says nothing; “Taming Terraform state across forty AWS accounts” says what, how big and for whom. Keep it short enough to fit on a schedule grid, and leave product names out unless the talk is truly about that product.

Structure the abstract for a fast reader

Reviewers skim. Put the most important information in the first two sentences: the problem, the context and what the audience will learn. A structure that works for most DevOps talks:

1. The situation. One or two sentences on the system, the team and the constraint.
2. The problem. What broke, what was slow or what did not scale.
3. What you did. The approach, including what you tried first and abandoned.
4. What the audience takes away. Two or three lessons, phrased as things they can do.

Avoid words that make reviewers sigh: “revolutionary”, “game-changing”, “deep dive” for a thirty-minute talk, and any sentence that could appear in a brochure. If your company sells something related to the talk, say so plainly and make sure the talk works without the product.

Use the private notes field

Many CFP forms have a field only reviewers see. Use it to explain why you are the right person to give the talk, link a recording of an earlier talk if you have one, and mention what the abstract could not hold: that your employer has approved the case study, that you can show real dashboards, or that a co-speaker covers the parts you do not. If you have never spoken before, say so. Many committees keep slots for first-time speakers, and some reward them: GrafanaCON gives first-time speakers a free pass.

Check what speaking costs you

Speaking is not always free. Many community events cannot pay travel: ContainerDays London, DevConf.IN and SREday London all say speakers cover their own travel, and SREday only takes talks given in person. Others help: Incontro DevOps Italia gives selected speakers a ticket, hotel nights and up to EUR 250 towards travel from elsewhere in Europe. Know this before you submit, so an acceptance does not turn into a budget problem.

Submit early, and more than once

Committees often start reading before the deadline, and some calls close early or extend. Submitting in the last hour means the most tired reviewers read your abstract. Deadlines are also the organizer’s, usually in their time zone. SCaLE 24x closes on 1 November 2026, FOSDEM’s main track on 16 November 2026 and SREcon Americas on 19 November 2026, so a talk drafted now can go to several of them.

Sending the same talk to several conferences is normal, and so is sending two or three different talks to one event when the call allows it. Rejection rates at popular events are high, and a rejection usually says more about the number of submissions than about your idea. Keep the abstract, improve it with any feedback, and send it to the next call that fits.

Before you press submit

Check that:

• the title says what the talk is about without a pun to decode;
• the first two sentences state the problem and the takeaway;
• the talk describes something you did, including what went wrong;
• you followed every instruction in the call, including length limits;
• the private notes explain why you are the right speaker;
• you know the deadline in the organizer’s time zone, and what the event pays for.

None of this guarantees a slot. It does make sure the committee reads your idea rather than skipping it, which is the part you control.