Objectives

A monitor answers "is it broken right now". An objective answers a different question: how much of the time has it been right, over a period you care about — and how much of your allowance for it being wrong is left.

That second question is the one contracts are written in. "The line runs within limits 99.5 % of the month" is a promise a plant manager can hold you to; "coolant is currently 78 °C" is not. An objective is where you write the promise down, so Pulse can tell you whether it is being kept before somebody else does.

Pulse calls it an objective. Elsewhere you may see the same idea called an SLO — a service level objective. They are the same thing.

What an objective is about

An objective is a promise about a condition — specifically about one Objective node in that condition's graph.

That has a consequence worth understanding up front: the condition defines what "good" means, and the objective defines how much good is enough. They are edited in different places on purpose. Retargeting 99.5 % to 99.9 % is not a change to the logic, so it does not touch the graph, does not bump its version, and does not affect anything else reading that graph.

An Objective node is true when things are as promised — the opposite polarity to an Alert node, which is true when something is wrong. A graph carrying both usually looks like this:

coolant avg₅ₘ > 80 ─┐
                    ├─ any of ─┬─→ Alert       "Coolant or spindle overload"
spindle avg₅ₘ > 16 ─┘          └─ not ──→ Objective  "Line stays within limits"

One gate, two consumers, one not between them. Drawing it this way is what stops the page and the promise disagreeing about where the limits are: change the threshold once and both follow.

Several objectives may point at the same node. That is normal and useful — a contractual promise over a month and an operational one over a week are different promises about one indicator.

Creating one

From Objectives → New objective, which opens a dedicated create page. Fill in the promise fields and describe the indicator inline:

Field	What it means
Name	Names both the objective and the condition it is measured on
Target	How much of the measured time the condition must hold. Between 0 and 100 %
Window	How far back the promise looks, rolling. Between 1 hour and 365 days
Coverage floor	How much of the window must be measured before Pulse reports a figure at all
Escalation policy	Who is paged when the objective burns its budget — required, like any monitor
Tags	Optional labels, the same tags every monitor carries

The indicator section below the promise fields lets you describe what has to hold using a sentence form — a reading that stays within a range, or any threshold the appliance can evaluate. For anything a sentence cannot express, Edit on the canvas opens the full condition editor; save the drawn condition there and the editor offers Create an objective, which returns to this page with that condition already chosen. The section's Use an existing condition picker reaches the same state for a condition that is already stored — including one that already carries a promise, since one condition can back several objectives (say, 99.5 % over thirty days for the contract and 99.9 % over seven for the team). On both of those paths the condition is shown read-only and only the objective is created; the graph itself stays edited in the editor, where everything else consuming it is visible too. After the objective is created, its page links to the condition editor for edits.

The window is rolling, not calendar-aligned: a 30-day objective always means "the last 30 days", never "since the first of the month".

A backtest card appears once the target and coverage floor are filled in. It shows how the objective would have performed against the condition's history before you save — useful for checking that the window and target make sense on real data.

After creation, Pulse navigates directly to the new objective's page — and backfills the window from stored sample history in the background. Within moments the page shows a figure labelled approximate instead of sitting at "Not enough data" until enough live measurement has accrued. The backfilled stretch ages out of the rolling window as real measurement replaces it, and the label disappears with it.

Reading the figures

An objective's page leads with the achieved percentage and the coverage beside it. Underneath:

Figure	What it means
Error budget	How much out-of-spec time the target allows over this window
Spent	How much of it has been used
Budget left	What remains, as a percentage. Negative when you are past the allowance
Burn rate	How fast it is going. 1.0 is exactly on pace; 2.0 spends the whole window's budget in half a window
Unmeasured	Time in the window Pulse could not evaluate

Budget left is usually the number to act on. "32 % left" says what you can still afford; "99.66 %" says how it has gone so far.

An approximate badge next to the figure means part of the window is backfilled history — recomputed from stored samples when the objective was created, rather than measured live. The page says how much of the window that covers, and the burndown draws that stretch dashed. Backfilled time carries the same caveat a backtest does: it is noisy, not lenient. It counts for what the page shows, and never for burn alerts.

Coverage is always shown, and it is not decoration

Every compliance figure in Pulse carries the fraction of the window it was measured on, in the same breath. This is deliberate: the standard way an availability figure lies is by quietly leaving out the time nobody was looking. A perfect 100 % measured on two days of a thirty-day month is not a good month.

Time Pulse could not evaluate is excluded from the calculation rather than counted as good or as bad. Unknown is not failure, and it is not success either.

Below the coverage floor, there is no figure

If less of the window was measured than the coverage floor requires, the objective reports Not enough data instead of a percentage — the numbers behind it stay visible, but the headline is the caveat.

That is the honest answer, and it is worth preferring to a number: a promise measured on a third of its window is not being kept or broken, it is not being measured.

The budget burndown

The chart shows the error budget draining across the window — flat while the condition holds, stepping down whenever it did not. The exact date range covered is shown below the chart.

A burndown says something the percentage cannot: when the budget went. A single cliff on a Tuesday is one incident to investigate. A steady slope is a process that is not quite right and never triggers anything.

Being told about it

An objective is a monitor underneath: it carries an escalation policy, tags and a mute switch of its own, and its alerts raise incidents into the same list as everything else. Being paged about an error budget works exactly like being paged about a dead PLC — nothing new had to learn how to reach you.

What it pages about is decided by its burn alerts — the ladder in the panel of the same name on the objective's page. An objective with no rungs measures and reports and wakes nobody, which is a perfectly reasonable thing to have.

Burn alerts read live measurement only — backfilled approximate history never pages anybody. A freshly created objective therefore shows an approximate figure immediately but holds its alerts until enough real coverage exists, exactly as it would have without the backfill.

Why not just alert when the objective breaks?

Because by then it is too late to do anything about it.

A 30-day objective at 99.5 % has about three and a half hours of allowance. An alert that fires when the allowance runs out tells you about a month you have already lost. What you want to know is that you are spending it too fast to last the month — while there is still budget left to protect.

That is what a burn alert watches: not the level, the rate.

Setting up the ladder

In the Burn alerts panel on the objective's page:

1. Check who gets paged — the escalation policy was picked when the objective was created and can be changed here
2. Add one or more burn alerts — or take the recommended ladder
3. Save

The two kinds of burn alert

Kind	Reads
Budget dropping too fast	"At least X % of the budget went in the last W"
Time until the budget runs out	"At the current pace, the budget is empty within N"

Budget dropping too fast is the one to start with. It needs no extrapolation, and you can check it against the burndown chart on the same page — which is worth a great deal when deciding whether an alert that fired was right.

Time until the budget runs out is friendlier to write and noisier to run. It measures the current pace over a quarter of the horizon you ask about, so a short excursion can project to a breach that a longer look would not have predicted.

The percentage is of the whole budget, not of the window

"8.5 % within 1 hour" means eight and a half percent of the whole month's allowance, spent inside one hour.

This is what makes the rungs comparable to each other and to the burndown. If each rung measured against its own window's share of budget, every threshold would mean something different and the ladder would be unreadable.

The recommended ladder

Two rungs, and the panel will fill them in for you:

Rung	Typically means
8.5 % in 1 hour	Something is badly wrong now — page somebody
43.2 % in 3 days	A slow bleed that will cost the month — raise a ticket

The shape matters more than the exact numbers: one fast rung that catches a crisis, one slow rung that catches a drift. A single rung either screams at every blip or misses the slow bleed entirely.

An objective has one escalation policy, so a ladder whose rungs must reach different people is drawn as two objectives over the same node — a fast promise routed to a policy that phones, a slow one to a policy that emails.

What an incident says

An incident is raised per rung, so two rungs firing are two incidents and clearing one does not clear the other.

Line 1 stays within limits is burning its error budget 13.26 % of the error budget was spent within 1 h; 32.3 % of the budget remains.

It is named after the objective rather than after the rung, because that is the sentence that means something to whoever is reading it. Which rung it was is in the numbers. The incident links straight back to the objective's page.

Incidents escalate, are acknowledged, and are resolved exactly like any other. When the rung goes quiet, the incident resolves by itself.

An unmeasurable objective holds its alerts open

If the objective drops below its coverage floor, its burn alerts read Can't tell rather than quiet.

An incident already open then stays open and stops climbing the escalation policy — Pulse will not wake more people over something it can no longer confirm, and it will not quietly declare all-clear either. Escalation resumes on its own when the data comes back.

This is the same treatment condition monitors get, and the reason is the same: a data point dying must never look like a problem being fixed.

Reading the ladder

Each rung shows what it currently says, with the figure behind it:

Badge	Means
Burning · 13.26 %	Firing. That much of the budget went inside this rung's window
13.26 %	Quiet, and this is how close it is
Can't tell	The objective is below its coverage floor — see above

Quiet rungs show their figure too, on purpose: the useful reading of a ladder is how close the quiet rungs are, not merely that they are quiet.

Editing the ladder

Rungs are edited together and saved together. A rung's window must be at least an hour and no longer than the objective's own window — a rung cannot ask about time the promise does not measure.

Removing a rung and saving retires it. Any incident it raised is resolved, and the rung's identity is not reused, so a later rung cannot inherit an old incident.

Muting

Mute in the objective's Actions menu (or in its list row's menu) silences it: burn alerts raise no incidents until it is unmuted. Measurement continues the whole time — the figures keep updating, and the page says plainly that the objective is muted.

It is the same mute every monitor has, because the objective is one.

Actions on the objectives list

Each objective in the list has a row menu with quick actions:

• Open — navigates to the objective's detail page.
• Open condition — opens the condition editor for the condition this objective is measured on.
• Mute / Unmute — the switch described above. A muted objective is marked in the list.
• Delete — removes the objective.

What happens to the condition when you delete an objective depends on whether anything else still uses it. If a monitor or another objective refers to the same condition, the condition and its history are left unchanged. If this objective is the only consumer, the condition is deleted with it. The delete dialog tells you which applies before you confirm.

Backtest

Nobody can pick a target they have never seen measured. The backtest recomputes what a promise would have said over a past range, from stored data point history, so you can choose a target with evidence instead of by guessing. It lives on the create page: once the objective exists, the same recomputation has already run automatically and its result is on the objective's page as the approximate backfill, so there is no second card to consult there.

It also answers what spent the budget — which branch of the condition was false while the budget drained, as a share of the spend. Because two branches can be false at the same moment, those shares do not add up to 100 %; each one reads "this part was false during N % of the spend".

A backtest is approximate, and the page says so

The recomputation samples on a coarse grid — the step is printed next to the figure. An excursion shorter than the step is either missed entirely or charged a whole bucket.

That makes the result noisy, not lenient: it is as likely to overstate as understate, and the error shrinks with the number of excursions rather than with the length of the range. A month with three two-minute breaches can come back as zero, or as thirteen minutes.

Use it to choose a target. Never quote it as the measurement — the recorded figure on the page above it is the measurement.

The backtest reaches back as far as data point history is retained, which is why the ranges offered are bounded.

In reports

Incident reports carry an objectives section: what each promise reported over the report's period, not over its own rolling window.

That substitution is the point. "Was this kept in June" is what a monthly report is asked, and answering it with a thirty-day rolling figure taken on the day the report was generated would silently include July and leave out most of June.

What Pulse cannot do here yet

Worth knowing before you promise something to somebody:

• Planned downtime is not recognised. Pulse has one kind of exclusion — absence of data — and it cannot tell a scheduled shutdown from a dead network. A plant that stops every weekend will sit below its coverage floor and report Not enough data rather than a number. If your plant does not run continuously, read this before setting a coverage floor.
• Burn alerts are evaluated once a minute, not on the five-second monitor loop. The shortest legal rung window is an hour, so a minute is well inside the resolution the question has.
• Windows are rolling only. A contractual "calendar month" is not yet expressible.
• One condition per objective. Promises about several things at once are drawn as one condition with an all of gate, not as several objectives.
• The condition can change underneath a window. If it does, the page says The condition changed during this window — the figure then covers two different definitions of "good", which is not wrong but is worth knowing before quoting it.