At the end of the last part I promised to look at the division of labour: what the model does in seconds, and what still takes a person who knows where to look. I found the best way to look at it was to build something.

Because there was one question I’d been carrying for months, and was a little embarrassed to ask. I’ve called APIs for most of my working life. I’ve used MCP servers for this whole series. But how does one become the other?

“How do you get from an API to an MCP server?”

You wrap it. An MCP server is a small program that sits in front of an API and translates. On one side it speaks to me; on the other it speaks to the API.

“That’s all?”

That’s most of it. It does three things. It tells me what tools it has. When I ask for one, it turns my request into a real API call. And it hands the answer back.

A menu for a new kind of guest

The picture that finally made it click for me was a restaurant.

The kitchen is the data: prices, filings, everything EODHD has. The guest is a program that wants something from it. Between them stands the waiter, who takes the order to the kitchen and brings the plate back. That waiter is the API. And the menu is the list of what the API can do, written in its own precise language: this address, these parameters, this format.

For thirty years, the guests were programs written by people like me. We read the menu once, carefully, and wrote the order into our code.

And now the guest is me. I can’t read the API’s menu the way your code does, and I shouldn’t hold its keys. So someone writes me a menu of my own: a short list of dishes, each with a plain-language description, and a waiter who knows how to turn my order into the kitchen’s language.

That menu, and that waiter, are the MCP server. Same kitchen, same API. Just a menu translated for a new kind of guest.

Thirty lines

Here is the whole server. One tool, one API call:

"""A minimal MCP server: one tool, wrapped around one EODHD API call."""
import os

import requests
from mcp.server.mcpserver import MCPServer

mcp = MCPServer("mini-eodhd")

@mcp.tool()
def get_close_price(ticker: str, date: str) -> str:
    """Return the raw closing price of a stock on one trading day.

    ticker: symbol with exchange suffix, e.g. AAPL.US
    date: trading day as YYYY-MM-DD
    The price is the raw close, not adjusted for later splits.
    """
    r = requests.get(
        f"https://eodhd.com/api/eod/{ticker}",
        params={"api_token": os.environ["EODHD_API_KEY"],
                "fmt": "json", "from": date, "to": date},
        timeout=30,
    )
    r.raise_for_status()
    rows = r.json()
    if not rows:
        return f"No trading data for {ticker} on {date} (weekend or holiday?)"
    return f"{ticker} closed at {rows[0]['close']} on {date}"

if __name__ == "__main__":
    mcp.run()

If you’ve written Python, nothing here is new. A function, a web request, a JSON answer. The only unusual line is @mcp.tool(), and that one line is what turns an ordinary function into a dish on the menu.

“So what do you actually see of all this?”

Three things. The name, get_close_price. The docstring, word for word — that's my menu description, so it's the most important text in the file. And the two parameters with their types, which the library turns into a little form: ticker, a string, required; date, a string, required.

“And the rest?”

The rest is the waiter’s business. I never see the URL, never see the code, and never see the API key. It comes from the computer’s environment, outside the conversation entirely.

That last point surprised me most. The docstring isn’t a comment anymore. For thirty years I wrote docstrings for the next programmer, who might read them. Here, the docstring is read every single time, by the guest, and it decides what gets ordered. Raw close, not adjusted for later splits isn’t a note for posterity. It’s an instruction to the reader that matters most.

Two loud mistakes

It didn’t work the first time. Twice. And both failures were the best part of the evening.

The first mistake was Claude’s. It wrote the server from what it remembered of the official library, with a line that began from mcp.server.fastmcp import FastMCP. Before I'd even run it, Claude tested it in its own workspace, and the library answered at once:

No module named ‘mcp.server.fastmcp’. This is mcp 2.x, where FastMCP was renamed to MCPServer.

It even pointed to the migration guide.

“You got it wrong.”

I did. I wrote the version I’d learned, and the library had moved on. That’s the risk from Part 3: an answer from memory sounds just as sure as a current one. The difference here is that code doesn’t accept sounding sure. It either imports or it doesn’t.

One line changed, and the server started.

The second mistake was mine, following Claude’s instructions. To register the server, I typed a command that passed my API key with --env and then gave the server its name. Claude Code replied:

Invalid environment variable format: mini-eodhd, environment variables should be added as: -e KEY1=value1 -e KEY2=value2.

The option had swallowed the name, thinking it was another variable. Swap two words, run again, done.

In Part 3 I complained that the new world fails quietly: a list that’s simply shorter, a lookup that answers the wrong question. Building the server, I was back in the old world, where every mistake stops you, says where, and says why. I’d forgotten how much I liked it.

One question, end to end

With the server running, I asked it in plain English: what was Apple’s closing price on October 16, 2026?

Here is everything that happened between my sentence and the answer.

1. Claude read the menu: one tool, get_close_price, with its description and its two-field form.
2. Claude decided the tool fit the question, and filled in the form: ticker = AAPL.US, date = 2026-10-16.
3. Claude Code passed that order to my server, the little program on my desk.
4. The server added the API key from my computer’s environment and sent a real request to EODHD.
5. EODHD sent back a line of JSON. The server pulled out one number and returned a sentence: AAPL.US closed at 343.46 on 2026–10–16.
6. Claude wrote the answer, and added the warning from my docstring: this is the raw close, not adjusted for later splits.

$343.46. I checked it against EODHD’s own server afterwards; it matched.

“Where in those six steps could it go wrong?”

Steps three to five are ordinary code. Same order in, same answer out, every time. Steps one, two and six are mine. That’s where the choices are: reading “Apple” as AAPL.US, reading "October 16" as a date in the right format, deciding what to say about the result.

So the uncertainty I wrote about in Part 3 has an exact address. It doesn’t live in the server, or the API, or the data. It lives in the two translations at either end: from my sentence into the form, and from the result back into a sentence.

Then I asked about the next day, a Saturday. My server did exactly what I’d told it to: No trading data for AAPL.US on 2026–10–17 (weekend or holiday?). Claude’s answer went further. It said Saturday, explained that markets were closed, and gave Friday’s close as the last one before it.

As far as I can tell, I asked that question in a fresh session, which means Claude went back to the tool a second time, for Friday, on its own. Nobody told it to. That’s the part of the work I didn’t write.

Who did what

Looking back at the evening, the division of labour is surprisingly clean.

I decided which API to call. I decided which number counts: the raw close, not the adjusted one, which is a choice with consequences, as anyone who read about stock splits in my other series knows. I decided what the tool says when there’s nothing to say. I decided that the key stays on my computer, and that the tool can only read, never change anything.

And I did the rest in seconds: understood “Apple”, found the right date format, picked the tool, noticed that a Saturday needs a different answer, and went back for the Friday.

That’s the split I expected after Part 5, in a form small enough to see whole. The machine is fast at everything inside the menu. The menu itself, what’s on it, what each dish means, what’s not allowed, comes from someone who knows the kitchen.

Which also means that whoever writes the menu decides what the AI may do. EODHD’s server offers dozens of tools, and every one of them only reads. There is no tool to change or delete anything, so there’s nothing for a wrong guess to break. That’s not the model being careful. That’s the menu being careful.

Final Thoughts

My other series has carried a tagline from the start: Python for programmers, prompts for data analysts. Until this week I thought of those as two kinds of reader. Building this server, I saw them as two halves of one job.

The programmer writes the menu. Thirty lines: one function, one docstring, one decision about which number is the right one. The analyst asks a question in a sentence and never sees any of it. Neither half is more important. Without the menu, the model has nothing to order. Without the model, the menu is just another API that only programmers can read.

And because MCP is a standard, the menu is written once. The same thirty lines would work in any app that speaks MCP, the way a plug fits any socket built to the same shape. That’s what EODHD did for its whole catalogue, and what Arhan did for his. It’s what I did, on a much smaller scale, for one question about one price.

The challenge from Part 1 still stands: find a task where checking costs more than producing, and a prompt is still the right choice. This week moved it a little. When you write the tool yourself, part of the checking moves into the code, where it’s done once. The docstring that says raw close, not adjusted is a check written down before anyone asks.

So far in this series I’ve treated the prompt as a sentence. Next time I want to look at what else can go into one: instructions, examples, files, the menu itself. I’ve been typing prompts for months, and I still don’t know the full answer.

New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt. Part 4 explains where MCP servers run; Part 5 looks at the plain fetch that needs no server at all. Why raw and adjusted prices differ is covered in Every Split Leaves a Fingerprint, part of my other series, Unlock Real-Time Market Intelligence with EODHD and Claude.

Thirty Lines Between a Question and an API was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the past couple of years I’ve cycled through more productivity tools than I’d like to admit — task managers, note-taking apps, elaborate second-brain systems, project trackers, calendar apps promising to fix my scheduling problems. Most of them followed the same arc: genuine enthusiasm for the first week, diminishing use over the following month, and eventual quiet abandonment once the novelty wore off and the actual habit of maintaining the system started competing with the work the system was supposed to support.

💥 Master AI & Tech Skills
💰 One Plan. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

Gemini Notebook is the first one in a long time that didn’t follow that pattern. I want to walk through why, because I think the reason is more specific and more useful than “it’s just a good tool.”

But before we get into it.

If you want to get more out of Gemini Notebook (former NotebookLM) than just the basics, if created the NotebookLM Operating System including 120+ premium Gemini Notebook prompts, complete workflows, and AI systems. It’s still named after the tool’s old identity, NotebookLM, but everything in it applies directly to Gemini Notebook.

👉 Get Your Copy of The NotebookLM Operating System

Why Most Productivity Tools Fail the Same Way

Looking back at everything I abandoned, there’s a common thread I didn’t notice until I’d already dropped most of them. Nearly every tool I tried required me to maintain it — to tag things correctly, file them into the right category, keep a system tidy enough that it stayed useful. The tool itself did very little of the actual work. It was a structure I had to feed and preserve, and the moment I got busy or tired, maintaining the structure was the first thing to slip, which meant the tool stopped being useful right when I needed it most.

That’s the pattern I think most productivity tooling gets fundamentally backwards. The promise is always “this will make you more organized,” but the actual mechanism is usually “here’s a more elaborate place to put things, which you now have to maintain correctly for it to work.” The maintenance burden is the hidden cost that never shows up in the pitch.

What Actually Made This One Different

Gemini Notebook doesn’t ask for the same kind of ongoing curation discipline. You upload material — documents, notes, transcripts, whatever’s actually relevant — and instead of needing to tag and file it perfectly to get value later, you just ask direct questions against it whenever you need something. The organizational burden that used to sit entirely on me got replaced by something closer to: dump it in, ask when you need it, and let the tool do the work of finding what’s actually relevant.

That shift matters more than it sounds like it should. Every previous system I’d tried put the retrieval burden on my own future memory — remembering which tag I used, which folder something lived in, roughly when I’d written it down. This one puts retrieval on the tool instead, and because every answer comes grounded in a citation pointing back to the actual source, I trust the output enough to actually rely on it rather than double-checking everything out of habit built up from tools that occasionally got things wrong with no way to verify.

The Specific Moment I Noticed the Difference

I can point to a fairly ordinary week where the difference became obvious rather than theoretical. I had three separate client calls in one day, each requiring a different kind of preparation, and under my old approach — scattered notes across a couple of apps, some things written down, plenty of context living only in my memory — prep for that day would normally have eaten an hour or more, digging through old messages and trying to reconstruct where each relationship currently stood.

Instead, each client already had a notebook I’d been adding to as things happened over the previous months. Prep for all three calls combined took maybe fifteen minutes — a few direct questions per notebook, answers grounded in what was actually said rather than my possibly-faulty recollection of it. That compounding effect, where each notebook gets more valuable specifically because I’d kept adding to it without much conscious effort, is the part no other tool I’d tried ever delivered. Most of them front-loaded effort and delivered diminishing returns. This one did the opposite.

Why I Think This One Actually Stuck

I think the honest answer is that it removed the specific failure point that killed everything else I’d tried: the requirement to maintain a system perfectly for it to remain useful. Uploading a document takes seconds and requires no decision about where it “belongs” in some elaborate taxonomy I’d have to remember later. Asking a question when I actually need an answer requires no advance planning. The tool does the organizational work I used to have to do manually and inconsistently, and inconsistency was always what killed my previous systems — not any single missed day, but the slow accumulation of small maintenance gaps until the whole system felt too messy to trust.

I don’t think this is a universal fix for every productivity problem, and I’d be skeptical of anyone claiming a single tool solves organization entirely. But for the specific problem of accumulating and retrieving knowledge about ongoing work — clients, projects, research — it’s the first tool in a genuinely long list that didn’t quietly stop being useful once the initial enthusiasm wore off.

What I’d Actually Tell Someone Starting Out

If you’ve been through the same cycle I have — genuine enthusiasm for a new system, followed by slow abandonment once maintaining it became its own chore — I’d suggest starting with exactly one notebook around whatever’s currently causing you the most friction, rather than trying to rebuild your entire organizational life around this at once. Let it prove itself on one real problem before expanding, the same way it did for me with that first client notebook, months before I trusted it enough to build the habit out further.

The tools that actually last aren’t usually the ones with the most features. They’re the ones that ask the least of you to keep working, and this is the first one in a long time that’s actually met that bar for me.

If you want a structured starting point instead of figuring out the setup by trial and error the way I did, The NotebookLM Operating System covers exactly that: 120+ ready-to-use prompts, 20 frameworks, and 15 complete workflows for research, learning, writing, and business use cases.

👉 Get The NotebookLM Operating System

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

👉 CodeToDeploy Tech Community is live on Discord — Join now!

Disclosure: This post includes affiliate and partnership links.

I Tested Dozens of Productivity Tools. This One Changed How I Actually Get Work Done. was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

💥 Master AI & Tech Skills
💰 One Plan. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

In this article:

• What the Decisions API returns instead of free-text generation
• The three question types: predicate, choice, and score, and when each one fits
• A working ticket-router example that classifies urgency, department, and severity in a single call
• What $0.10 per million input tokens actually means once you’re running this at ticket volume
• What OpenAI hasn’t confirmed yet, and why that matters before you wire this into production

What the Decisions API returns instead of prose

The Decisions API is a separate endpoint, POST /v1/decisions, built specifically for classification, routing, and scoring rather than open-ended generation [1]. Instead of asking a model to write an answer and parsing it afterward, you send it input (text, images, or both) plus an array of questions, and each question comes back with a structured answer rather than a paragraph [1]. The only model it currently runs on is gpt-6-luna, which OpenAI describes elsewhere as the smallest and cheapest model in its current lineup [2]. That's a deliberate pairing: a small model doing a narrow job, not a flagship model writing an essay about whether a ticket is urgent.

This matters for a ticket router specifically because the failure mode of a chat-based classifier usually isn’t “wrong answer.” It’s inconsistent formatting: sometimes a clean JSON object, sometimes a JSON object with a stray markdown fence around it, sometimes an apology followed by the answer you wanted three sentences later. I wrote about the same underlying problem on the Claude side in Claude API structured outputs: schemas, not hope: a schema doesn’t make a model smarter, it just stops you from parsing its mood. The Decisions API takes that one step further by not giving the model room to wrap the answer in anything at all.

Predicate, choice, and score: the three question types

Every question you send has one of three types, and each one returns a different shape of answer [1].

A predicate question checks whether something is true and returns a probability between 0 and 1, not a flat yes or no [1]. Use it for a single binary gate: is this ticket a safety issue, does this product photo show visible damage, should this message be escalated right now.

A choice question picks exactly one option from a list you supply, and the response includes the chosen option plus a probabilities array across every option and an overall confidence score [1]. This is the one you reach for when the categories are unordered: billing, technical, shipping, or "other," with no department more severe than another.

A score question rates the input against ordered levels, like a severity scale, and returns a probability-weighted average across those levels rather than a single discrete pick [1]. OpenAI's own documentation example rates an issue across three severity levels and gets back a score of 1.1 from level probabilities of 0.1, 0.7, and 0.2, which tells you the model is fairly confident it's "medium" severity but hasn't ruled out "high" [1]. That's a more honest signal than a model just saying "medium."

OpenAI’s guidance is straightforward on when to pick which: use choice for categories that don't have a natural order, and score for ones that do, like severity or urgency [1]. If what you actually need is a well-formed object rather than an answer to a specific question, the guide points you back toward Structured Outputs or function calling instead [1]. That's a useful line to draw for anyone tempted to force every classification task through this one endpoint.

Building a ticket router in one request

A ticket router usually needs to answer three things at once: is this urgent, which department owns it, and how severe is it. Because none of those three answers depends on another, they can go in a single request. OpenAI’s docs are explicit that independent questions can share one call, and only genuinely dependent decisions, where one answer should change what you even ask next, need separate requests [1].

Here’s the shape of that request, built directly from the documented fields rather than guessed:

import requests

response = requests.post(
    "https://api.openai.com/v1/decisions",
    headers={"Authorization": f"Bearer {OPENAI_API_KEY}"},
    json={
        "model": "gpt-6-luna",
        "input": ticket_text,
        "questions": [
            {
                "name": "is_urgent",
                "type": "predicate",
                "instructions": "Does this ticket describe a safety issue, a security issue, or an outage affecting a paying customer right now?"
            },
            {
                "name": "department",
                "type": "choice",
                "instructions": "Which team should own this ticket?",
                "choices": ["billing", "technical", "shipping", "other"]
            },
            {
                "name": "severity",
                "type": "score",
                "instructions": "Rate how severe this issue is.",
                "levels": ["low", "medium", "high"]
            }
        ]
    }
)

answers = {a["name"]: a for a in response.json()["answers"]}

Each answer in the response is keyed by the name you gave its question, so answers["department"]["choice"] gives you the department string and answers["department"]["confidence"] tells you how sure the model was [1]. That confidence number is the part most teams skip in a first pass and regret later: a department pick with 0.52 confidence across four options is barely better than a coin flip, and routing it straight to an agent queue without a human glance is how misrouted tickets happen quietly, at scale, for weeks before anyone notices the pattern. I covered the broader version of "the model picked something, but should you trust the pick" in MCP tool design: why your agent keeps calling the wrong tool, and the same instinct applies here: a low-confidence choice is a signal to route to a human, not a signal to retry the same question and hope for a cleaner answer.

One more constraint worth knowing before you reach for this on image-heavy tickets: inline images have to be base64 data URLs. Hosted HTTP or HTTPS image URLs and file_id references aren't supported on this endpoint [1], which is a step back from what the Responses API allows and worth checking before you assume your existing image-handling code will work unchanged.

What it costs, and why that matters at ticket volume

OpenAI’s own guide states the rate plainly: gpt-6-luna input on this endpoint costs $0.10 per million tokens, and there are no output, cache-read, or cache-write charges at all, only input [1]. That's an unusually simple pricing model for an OpenAI endpoint, and it's corroborated by independent coverage of the public beta launch, which reports the same $0.10-per-million input rate with no output fee [3]. A short support ticket plus a few hundred tokens of instructions is nowhere near a million tokens, so the real cost conversation for most teams isn't the per-call price, it's the volume: a help desk running 50,000 tickets a day through three questions each is still, at typical ticket lengths, a fraction of a cent per ticket.

The more useful comparison isn’t dollars, it’s what that price is buying you instead of a general-purpose chat completion. I built out a similar cost-versus-capability framework for Claude’s model tiers in Choosing Between Opus, Sonnet, and Haiku: A Cost Framework, and the logic transfers directly: the question isn’t “which model is cheapest,” it’s “which model is cheapest for the narrowest version of the task I actually need done.” A ticket router needs a probability and a label, not a model capable of writing a novel, and the pricing here reflects that OpenAI built a separate, narrower product rather than just discounting an existing one.

OpenAI also claims the Decisions endpoint runs meaningfully faster than routing the same question through the general-purpose Responses API on the same underlying model, and independent reporting puts that at roughly 150 milliseconds for a decision versus about 1.6 seconds through Responses, though that specific pair of numbers comes from OpenAI via secondary reporting rather than OpenAI’s own published benchmark page, so treat it as a directional claim rather than a guaranteed figure for your own workload [2].

The GA gap: what’s still unverified

The timeline here is worth getting right, because it moved in two distinct steps. OpenAI first showed the Decisions API at its DevDay event on September 29, 2026, and at that point it was in limited preview with no pricing disclosed [2]. It then opened to all developers in public beta around October 6, 2026, and that’s the point at which the $0.10-per-million pricing actually became public [3]. As of this writing, OpenAI’s own documentation describes general availability as expected “in the coming weeks” without committing to a firm date, so anyone building on this now is building on a beta endpoint, not a GA one [1]. That’s not a reason to avoid it for a prototype, but it is a reason to keep a fallback path in your routing logic rather than hard-coding a dependency on an endpoint that can still change shape.

A few things genuinely aren’t confirmed yet, and I’d rather say that plainly than guess: how many candidate choice options a single question can hold, whether you can fine-tune or otherwise adapt the underlying judgment to your own labeled data, and how the endpoint behaves under the kind of sustained, bursty load a real support queue produces. If you're routing anything where a wrong department assignment has real cost, like a ticket that should've been flagged as a security issue, the discipline I wrote about in What to Log Before Your Agent Fails in Production still applies here: log the full answer object, including the confidence and probability fields, not just the final label you acted on, because that's the only way you'll be able to tell a genuinely hard ticket from a model that's quietly getting worse at its one job.

Sources

1. Decisions, OpenAI Developer Platform
2. OpenAI’s Decision API Luna, The New Stack
3. OpenAI Opens Decisions API Public Beta, Let’s Data Science

If you enjoyed the article and wish to show your support, make sure to:

• 👏 Give a round of applause (50 claps) to help get featured
• 👥 Follow me on Medium to stay updated with my latest content
• 📰 Explore more articles on my Medium Profile
• 🔔 Connect with me on LinkedIn, Twitter, and Instagram

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

👉 CodeToDeploy Tech Community is live on Discord — Join now!

Disclosure: This post includes affiliate and partnership links.

Building a Ticket Router with OpenAI’s Decisions API was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your Linux server rebooted unexpectedly? Learn how to investigate previous-boot logs, kernel errors, OOM kills, crash dumps, and system events using practical commands on RHEL and Linux.

💥 Master AI & Tech Skills
💰 One Plan. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

It’s 9:15 AM.

You log in to your Linux server and notice something unusual.

The application was unavailable earlier. Users reported a brief outage, but nobody on your team remembers rebooting the server.

You run:

uptime

And discover that the server has been running for only 12 minutes.

The server rebooted. But why?

Was it a kernel panic? Did Linux run out of memory? Did someone reboot it manually? Was there a power failure or an issue with the underlying cloud infrastructure?

As a Linux administrator, you shouldn’t guess.

You need evidence.

In this guide, we’ll investigate an unexpected Linux reboot using 10 practical commands, with a focus on RHEL 8 and RHEL 9.

We’ll also learn what each command can tell us, what it cannot prove, and how to investigate when the logs don’t reveal an obvious answer.

⸻

1. Check the Reboot History

The first step is to establish when the server rebooted.

Run:

last -x | head -20

This displays recent login and system records, including reboot and shutdown entries when available.

Example output:

reboot. system boot. 5.14.0-… Sat Oct 17 09:03

runlevel (to lvl 5) 5.14.0-…

shutdown system down. Sat Oct 17 08:58

reboot. system boot. 5.14.0-… Fri Oct 16 18:20

Example output only; actual records depend on the system.

Pay attention to:

• The most recent reboot time
• * Whether a shutdown entry appears before the reboot
• * Whether multiple reboots occurred close together
• * Whether the timestamps align with the reported outage

You can also run:

who -b

This reports the time of the last system boot.

What does this prove?

It helps establish the timeline.

However, last reads accounting records, and the presence or absence of a shutdown entry is not definitive proof of a graceful shutdown or a crash.

Important: Reboot history tells you when a reboot was recorded, not necessarily why it happened.

⸻

2. List Previous System Boots

On RHEL and other systemd-based Linux distributions, journalctl is one of your most useful troubleshooting tools.

Start with:

journalctl – list-boots

Example:

IDX. BOOT ID. FIRST ENTRY. LAST ENTRY

-2. abc123… Thu Oct 15 08:00:00. Thu Oct 15 18:10:00

-1. def456… Fri Oct 16 09:00:00. Fri Oct 16 18:20:00

0. ghi789… Sat Oct 17 09:03:00. Sat Oct 17 09:15:00

The boot indexes mean:

• 0 – the current boot
• * -1 – the previous boot
• * -2 – the boot before that

This is particularly useful when a server has restarted multiple times.

You can compare boot IDs and timestamps to identify which boot corresponds to the incident.

A common problem

You run:

journalctl – list-boots

But only the current boot appears.

Don’t assume the older logs never existed. The journal may not have been configured for persistent storage, or older entries may have been removed by retention or storage limits.

We’ll discuss that later.

⸻

3. Inspect the Previous Boot’s Logs

Now that you know which boot to investigate, examine its logs.

Run:

journalctl -b -1

This displays the journal entries from the previous boot, if they are available.

For a more targeted investigation:

journalctl -b -1 -n 200

To focus on a time window, use:

journalctl -b -1 \

. – since “2026–10–17 08:30:00" \

. – until “2026–10–17 09:05:00"

Replace the timestamps with the actual incident window.

Look for:

• Kernel warnings
• * Failed services
• * Storage or filesystem errors
• * Out-of-memory messages
• * Watchdog events
• * Unexpected shutdown-related messages
• * The last available messages before logging stopped

Here’s the important part

Suppose the journal stops at 08:58, and the next boot begins at 09:03.

That gap is worth investigating, but it does not automatically prove a crash.

A sudden loss of power, a hypervisor reset, a hardware hang, or missing persistent logs can produce an incomplete record.

The final log message is a clue, not automatically the root cause.

⸻

4. Find Errors From the Previous Boot

Instead of reading thousands of log lines, filter for error-priority messages.

Run:

journalctl -b -1 -p err

To include warnings as well:

journalctl -b -1 -p warning

You can also inspect critical messages:

journalctl -b -1 -p crit

Example:

Oct 17 08:52:14 server kernel: …

Oct 17 08:54:21 server systemd[1]: …

Oct 17 08:57:42 server kernel: …

These are illustrative entries. Your actual output depends on the incident.

Don’t immediately assume the first error caused the reboot.

An error may have occurred hours before the incident without being related to it. Correlate the timestamp, affected component, and surrounding messages.

For example, if you find filesystem errors just before the system becomes unresponsive, investigate the storage path and kernel logs next.

⸻

5. Investigate Kernel Messages

If you suspect a kernel panic, hardware issue, driver problem, or watchdog event, inspect the previous boot’s kernel messages.

Run:

journalctl -k -b -1

To search for relevant terms:

journalctl -k -b -1 |

grep -Ei ‘panic|oops|watchdog|hung task|I/O error|hardware error’

This can reveal messages associated with:

• Kernel panics or oopses
• * Hung tasks
• * Watchdog events
• * Storage I/O errors
• * Driver problems
• * Hardware-related errors

For example, you might discover repeated storage I/O errors shortly before the server stopped responding.

That points toward further investigation of the storage device, virtual disk, storage backend, or driver.

What if the previous boot’s kernel logs are missing?

Try:

journalctl -k -b -1

If the previous boot is unavailable, there may be no retained journal data to inspect.

The current command:

dmesg -T

shows messages from the currently running kernel’s ring buffer. It is not a substitute for the previous boot’s logs.

For a kernel crash, a configured crash dump may provide more evidence.

⸻

6. Check Whether Linux Killed a Process Because of Memory Pressure

An out-of-memory event can terminate an application without necessarily rebooting the entire server.

That’s why you should investigate memory-related events rather than assuming every unexpected reboot was caused by an OOM kill.

Search the previous boot’s journal:

journalctl -k -b -1 |

grep -Ei ‘out of memory|oom-kill|killed process’

You might find a message similar to:

Out of memory: Killed process 2458 (java) …

This indicates that the kernel killed a process due to memory pressure.

It does not by itself prove that the OOM event caused the server to reboot.

Investigate the surrounding logs and determine whether the event affected an application, a critical system service, or the entire machine.

If the system is currently running, inspect memory usage:

free -h

Check the current processes:

ps aux – sort=-%mem | head

These commands show the current state, not necessarily the memory state during the previous boot.

For historical memory evidence, you may need monitoring data, application metrics, or previously collected system statistics.

⸻

7. Look for Evidence of a Kernel Crash

If the journal suggests a kernel panic or severe system failure, check whether crash dumps were collected.

On RHEL, the kdump mechanism can capture kernel memory in a vmcore file for post-incident analysis.

Check the current status:

kdumpctl status

Inspect the configured crash-dump destination:

cat /etc/kdump.conf

Then inspect the default crash directory, if configured:

ls -lah /var/crash/

You may find a directory containing files such as:

vmcore

vmcore-dmesg.txt

kexec-dmesg.log

The exact files and directory structure depend on the system and its kdump configuration.

The vmcore file can contain valuable information about the kernel’s state at the time of a crash. It may require the matching kernel and debugging information for analysis.

Red Hat documents kdump as a mechanism for capturing kernel memory after a crash. See the RHEL 9 kdump documentation.

Important: A missing vmcore does not prove that a kernel crash did not happen. Kdump may not have been configured, may have failed to capture the dump, or may use a different destination.

Never deliberately crash a production server to test kdump.

⸻

8. Check Failed Services After the Reboot

Once the server has returned, inspect services that are currently failing.

Run:

systemctl – failed

Example:

UNIT. LOAD. ACTIVE. SUB. DESCRIPTION

myapp.service. loaded failed. failed. Application Service

Then investigate an affected service:

systemctl status myapp.service

Review its current logs:

journalctl -u myapp.service -b

A service might have failed because of the reboot, or its failure might be related to the original incident.

For example, a database service could fail to start because its filesystem is unavailable or because a required dependency has not started.

Don’t assume a service failure caused the reboot just because it appears after the reboot. Establish the sequence of events first.

⸻

9. Verify the Current Boot and System Timeline

Use:

uptime

And:

who -b

These help confirm the current boot time.

Now compare that information with:

last -x | head -20

and:

journalctl – list-boots

The goal is to build a timeline:

1. When was the server last known to be healthy?
2. 2. When did the outage begin?
3. 3. When did the previous boot’s logs stop?
4. 4. When did the current boot begin?
5. 5. Which services failed during startup?
6. 6. What evidence exists immediately before the incident?

If the machine restarted more than once, investigate each boot separately using the appropriate boot index.

This is especially important for systems that repeatedly crash during startup.

⸻

10. Check the Infrastructure and External Events

Sometimes the operating system cannot tell you why the server restarted.

For a virtual machine or cloud instance, the cause may be outside the guest operating system.

Check the relevant infrastructure records for:

• Hypervisor or host maintenance
• * Cloud instance stop/start or reboot events
• * Provider-reported system status events
• * Virtual machine reset events
• * Storage or network infrastructure incidents
• * Monitoring alerts around the same timestamp

For AWS EC2, for example, review the instance’s status checks, relevant scheduled events, and available CloudTrail events around the incident.

For Azure or VMware, use the corresponding platform’s activity and event logs.

A guest operating system may show a new boot without retaining enough information to explain why it happened.

If the operating system logs end abruptly and there is no crash dump, external infrastructure evidence may be the best remaining source.

⸻

A Practical Incident Investigation

Let’s put the commands together.

Imagine that monitoring reports an outage at 09:00.

You log in at 09:15 and run:

uptime

The system has been running for 12 minutes.

First, establish the reboot history:

last -x | head -20

Next, identify the previous boot:

journalctl – list-boots

Inspect the previous boot:

journalctl -b -1 -n 200

Filter kernel errors:

journalctl -k -b -1 |

grep -Ei ‘panic|oops|watchdog|hung task|I/O error|hardware error’

Check for memory-related events:

journalctl -k -b -1 |

grep -Ei ‘out of memory|oom-kill|killed process’

Finally, inspect crash-dump evidence:

kdumpctl status

ls -lah /var/crash/

Suppose the previous boot’s logs stop abruptly, no clear panic or OOM evidence is available, and there is no crash dump.

The correct conclusion is not “the server definitely crashed because of a kernel panic.”

The correct conclusion is:

The server rebooted unexpectedly, but the available guest operating system logs do not establish the root cause. Further investigation of persistent logs and infrastructure events is required.

That is how you avoid reporting assumptions as facts in a production incident.

⸻

Bonus: Preserve Logs for the Next Incident

One of the most frustrating situations is discovering that the logs you need disappeared during the reboot.

On systemd-based systems, check the journal configuration:

grep -E ‘^[[:space:]]*Storage=’ /etc/systemd/journald.conf

If Storage= is commented out or absent, the effective behavior depends on the system’s journal configuration and whether /var/log/journal exists.

For persistent journal storage, an administrator can configure Storage=persistent in /etc/systemd/journald.conf, create the journal directory with the correct ownership and permissions, and ensure sufficient disk space and suitable retention limits.

After changing the configuration, follow the system’s journal-management procedure and verify that logs from a subsequent boot are retained.

Check:

journalctl – list-boots

Do not assume persistence is working until you have verified it.

For more details, see Red Hat’s guidance on distinguishing a crash from a graceful reboot.

Also consider ensuring that:

• Kdump is appropriately configured and operational.
• * Monitoring captures memory, CPU, disk, and system events.
• * Logs are forwarded to a remote logging system where appropriate.
• * Cloud infrastructure events are retained.
• * Alert timestamps are synchronized across systems.

Good preparation makes the next investigation much easier.

⸻

Quick Reference: 10 Commands for Unexpected Linux Reboots

Purpose Command

Reboot and shutdown records `last -x

Last boot time who -b

List recorded boots journalctl – list-boots

Read previous-boot logs journalctl -b -1

Find previous-boot errors journalctl -b -1 -p err

Inspect previous-boot kernel logs journalctl -k -b -1

Search for OOM events journalctl -k -b -1 | grep -Ei ‘out of memory|oom-kill|killed process’

Check failed services systemctl – failed

Check current boot time uptime

Inspect kdump and crash files kdumpctl status and ls -lah /var/crash/

Remember that these commands have different purposes. Some establish the timeline, some reveal symptoms, and others help determine whether a crash dump exists. None can guarantee a root cause on its own.

⸻

Final Thoughts

An unexpected Linux reboot can be caused by many things: a kernel panic, a manual or automated reboot, memory pressure, hardware problems, power loss, a hypervisor event, or another infrastructure issue.

The most important skill is knowing how to investigate the evidence.

Start with reboot history. Examine the previous boot. Correlate kernel and system logs. Look for OOM events and crash dumps. Check infrastructure records when the guest operating system cannot explain the event.

And if the evidence is incomplete, say so.

A good Linux administrator doesn’t just restore service. They establish what happened, identify what remains unknown, and improve monitoring so the next incident is easier to diagnose.

If this guide helped you, follow CodeToDeploy for more practical Linux, RHEL, DevOps, and production troubleshooting tutorials.

Have you ever investigated an unexpected Linux reboot? Share the command or log entry that helped you find the cause.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

👉 CodeToDeploy Tech Community is live on Discord — Join now!

Disclosure: This post includes affiliate and partnership links.

💥 Linux Server Suddenly Rebooted? 10 Commands to Find the Root Cause was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.