This is the operator’s manual — the practical, end-to-end guide to using the platform once you are past the first login. It walks the whole workflow in the order you will actually meet it: get data flowing, set up monitoring, ship and search logs, alert on metrics, turn on detections, read the analyst’s verdicts, work incidents, and keep your team and your customers informed. No reference-doc shorthand — just how it works and how to use it well.
24Observe has a lot of surface area — monitoring, logs, metrics, detections, an analyst, a topology map, on-call. It is far easier to learn once you see the single idea underneath all of it.
Everything the platform does is a different way of noticing that something needs attention, and every one of those ways funnels into the same place: an incident. A monitor that fails opens an incident. A metric that crosses a threshold opens an incident. A security detection that matches opens an incident. A host that goes quiet opens an incident. They look like different features, but they all arrive at the same destination — and once an incident exists, the analyst investigates it and the context graph tells you what it touches.
So the platform is really a funnel. The wide top is all the ways you can feed it signal — checks, logs, metrics, device telemetry, agent traces. The narrow bottom is a single, consistent incident-and-investigation flow that works the same no matter which input opened the incident. Learn that flow once and you have learned the product; everything else is just choosing which signals to send and how sensitive to make them. The sections below follow that funnel from top to bottom.
There are four front doors. Use whichever fit what you want to see — most teams use several.
The fastest start: point a monitor at a website, API, port, or certificate. No install — the platform checks it from the outside on the interval you set, and opens an incident when it fails or degrades.
Send application and system logs over HTTPS, from your existing log shippers, or from common cloud sources. They are searchable within seconds, and detections run over them automatically.
Install the lightweight collector on a server to gather its logs and metrics, or have it poll your network devices. One command per host; the network gear needs nothing installed on it.
If you run AI agents or instrumented services, point their telemetry at the platform to get cost, latency, and security visibility alongside everything else.
Choose a type — website, API, port, certificate, keyword, or an inverted heartbeat where your job pings the platform on success — and set the interval, the timeout, and what counts as a failure. You can treat a slow response as degraded and alert on that before it goes fully down, and you can run checks from more than one location so a single bad vantage point does not flip a healthy service.
Beyond up-or-down, set thresholds on the numbers that matter — host CPU and memory, request latency, queue depth, interface utilisation on a network device. Pick the metric, the comparison, and the window, and a breach opens an incident through the same pipeline as everything else. This is how you catch the slow degradations that a simple availability check never sees.
Every incident routes through your notification channels — email, chat tools, phone and text, or a signed webhook to your own systems. You decide which channels carry which severities, and on-call schedules decide who gets the page. Set this up once and it applies to every kind of incident, security or operational.
Before a deploy or a maintenance window, schedule a quiet period for the affected monitors. Checks keep running so you still have the data, but the alerts pause, and your uptime math respects the window so planned work does not dent your reliability numbers or wake anyone.
Searching logs. Type the words you remember. Plain text works for most questions, and a readable filter syntax narrows it down by service, level, or any field — no query language to study. Live tail streams new matching events as they land, so you can watch a deploy or an incident unfold in real time. Repeating patterns are grouped so ten thousand near-identical lines collapse into a single row with a count, and recurring errors are tracked so you see each distinct bug once rather than a thousand times.
Turning on detections. The platform ships with a large library of prebuilt detections grouped into packs — authentication abuse, data exfiltration, secret exposure, web attacks, threat-intel matches, AI-agent threats, cloud control-plane, host security, and infrastructure health. Enable the packs that match your environment and they begin matching your incoming events immediately. Each detection that matches opens an incident, which the analyst then investigates. You can tune any detection’s threshold to your own volume, and you can write your own in a single readable line — a query, a window, a threshold, and a severity.
The important thing to internalise is that a detection is not a dead-end alert. It is the start of an investigation. You do not have to triage detections by hand; you read the verdicts the analyst produces. See the next section, and the dedicated SIEM & detections page for the full picture.
When something opens an incident, you do not start from a blank page. The analyst investigates it automatically and attaches a verdict. Read it top to bottom: the classification tells you whether this is a security or an operational problem; the root cause states, in plain language, what actually happened; the blast radius lists what it touches; the evidence section links every claim to a record you can open and check; and the recommended fix names the next action. A confidence level tells you how seriously to take it, and if the analyst was not sure, it says so and hands the incident to you rather than guessing.
From there the workflow is simple. Acknowledge to stop the paging while you work — the incident stays open, but the team knows someone has it. Post updates as you learn more; those can flow straight to your public status page so customers are informed without you writing a separate notice. If the analyst proposed a response action — block a source, roll back a change — you review and approve it; nothing is executed automatically. When it is fixed, resolve it.
Group related work into a case. When several incidents are really one event, gather them into a case — a single investigation with its own status, owner, and notes. Often the platform does this for you: storm correlation automatically collapses many incidents that share a root cause into one case, so a big failure is one thing to work, not fifty. And when you correct a verdict — confirm it, downgrade it, add context — that correction teaches the analyst, so it gets better at reading your environment over time.
A live map of your services, hosts, and devices with the dependencies between them, coloured by health. During an incident it is the fastest way to see what is broken and everything downstream of it. Learn more →
Define who is on call with rotations and overrides, and build escalation chains so an unacknowledged incident steps up to the next responder. One schedule covers every kind of incident.
Publish a status page, group monitors into components, post incident updates that appear automatically, and let customers subscribe — so the operator is not also the press office during an outage.
Those are the day-to-day surfaces. Settings that affect the whole organisation — inviting teammates, assigning roles and permissions, managing API tokens, billing, and data retention — live in the admin guide, because they are an administrator’s job rather than an operator’s. And if you would rather drive any of this from scripts or an AI agent than from the dashboard, every action here is available through the API; the agent cookbook shows you how.
That is the whole loop: feed the platform signal, decide what healthy means, let detections and the analyst do the noticing and the investigating, and work incidents from an answer instead of a blank page. Once it is running, the platform should feel less like a set of tools you operate and more like a colleague who has already done the first hour of every investigation before you sit down.
New users sometimes ask what a normal day looks like. A few patterns settle in within the first week. The morning sweep is the simplest: open the incident list, and because each open incident already carries a verdict, you are reading conclusions rather than starting investigations — a few minutes tells you whether anything overnight needs a human, instead of an hour of catching up. Watching a deploy becomes a habit: open live tail filtered to the service you are shipping, keep the topology map in view, and you see errors or a metric turning the moment they appear, while you can still roll back cheaply.
The incident itself is where the platform earns its keep. The page arrives, the verdict is already attached, you acknowledge to quiet the noise, read the root cause and blast radius, post an update that your status page picks up automatically, approve any proposed fix, and resolve — a flow that used to span four tools, done in one. When several incidents are really one event, you work the case the storm-correlation already built rather than fifty separate pages. The weekly look-back closes the loop: skim resolved incidents and analyst verdicts, correct any the analyst got wrong so it learns, tune a detection that has been a little noisy, and note any monitor or threshold worth adding. None of this is heavy process — it is just what falls out naturally when noticing and investigating are handled for you and your attention is freed for the decisions that actually need a person.
You do not have to adopt everything at once, and you should not try to. The teams who get the most from the platform tend to start narrow and widen deliberately. Begin with a single service or a single class of problem — the thing that pages you most often — and get its monitors, its logs, and one or two detections genuinely trustworthy before you expand. A handful of monitors you believe is worth far more than a hundred you have learned to ignore, because the moment an alert becomes background noise it has stopped doing its job. Once that first slice feels solid and quiet, add the next service the same way, and let coverage accumulate as confidence does.
The same principle applies to the analyst and to enforcement. Let it investigate in an advisory role first, read its verdicts against incidents you already understand, and only widen its remit once it has earned your trust on familiar ground — exactly the way you would extend responsibility to a new hire. Treat the early weeks as a conversation: every verdict you confirm or correct, every threshold you nudge, every detection you tune is you teaching the system what your environment considers normal. That investment compounds. A platform you have spent a month shaping around your own services is dramatically more useful than one fresh out of the box, and the shaping is the ordinary work of using it — not a separate project you have to schedule.
Send your first signal, turn on the packs that fit, and let the analyst start working incidents while you set up the rest.