When no card appears

An alert fired and no card arrived. That is usually Nodrik working rather than Nodrik broken — but “working” is not a satisfying answer unless you can tell which of the reasons applies, so this page names all of them and the order they are decided in.

Every alert that becomes an investigation ends with a card, whether Nodrik found the culprit or ran out of road. There is no case where an investigation happens quietly. So a missing card means either the alert never became an investigation, or the card never reached Slack.

The order things are decided in

The order matters, because more than one reason can be true at once and only the first one that fires is the reason. An incoming alert meets these gates, in this sequence:

1. Is it a closing notice? Cloud Monitoring sends one when an incident clears itself. Nothing is investigated: there is no longer anything to investigate, and a card saying “it stopped” is not worth a message.
2. Does the plan allow it? No plan on the workspace, or a lapsed subscription. Checked before anything else, so an alert that is not being investigated cannot quietly fold into one that is.
3. Has today’s cap been reached? Only asked of a workspace in good standing, and only after the two commercial answers above have come back clean — a lapsed account is refused for that reason, never relabelled as a busy day.
4. Is this cause muted? Behind the plan gate, because a workspace nothing is being investigated for has nothing to mute. Ahead of coalescing, because folding into an open card would update that card and post a reply to its thread — exactly the noise somebody pressed Mute to stop.
5. Is there already an investigation for this? If so it folds in. Otherwise a new investigation starts, and you get a card.

Each of steps 2 to 5 is worked through below.

The plan gate

An alert is only investigated for a workspace with an active plan. Two states fail that: no plan has ever been chosen, and the subscription has lapsed. In both, everything else about your workspace carries on — projects stay granted, Slack stays connected, and setup remains editable. Only the thing a plan pays for stops, which is investigating.

Nodrik says so in the channel rather than going silent, at most once a day. The daily throttle is deliberate: the useful message is “nothing is being investigated on this account and here is why”, and the second one that day adds nothing except the impression that Nodrik is broken in a new way.

Two consequences worth knowing:

• The notice only reaches you through Slack. A workspace that has not connected Slack, or has removed Nodrik from the channel, gets no notice at all — there is no console banner for it and nothing is written to the notification bell. Home’s lapsed banner is the thing that says so instead, so the console tells you but the alert does not.
• A declined alert leaves no record. No investigation is opened, so there is nothing in the console’s history to find later. The absence is the only evidence.

Getting out of it is subscribing, or subscribing again — see Plans and billing.

The daily cap

This is the only limit in Nodrik that ever declines an alert. The monthly allowance is soft and always has been: going past it costs nothing, stops nothing, and never switches anything off mid-incident. The daily cap is the one hard backstop behind that promise, and it exists so a single catastrophic day cannot spend a month’s capacity by itself.

It is a tenth of your monthly allowance, so it moves when your tier does and moves again when you buy extra investigations — the numbers, and how they are worked out, are on Plans and billing. Your current cap and today’s count against it are on the console’s Usage page, which is the place to check when you suspect this is what happened.

When it is reached, Nodrik says so in the channel — the same once-a-day throttle as the plan notices, and the same words for everybody, because a workspace in good standing that has simply had a very loud Tuesday should not be shown copy written for somebody whose card failed. New investigations resume when the day resets.

Two things do not spend it. A test alert from the console is excluded from both the daily cap and the monthly allowance, so proving the product works never costs you capacity. A re-run, on the other hand, does count: a re-run opens a genuinely new investigation, which is the whole reason it is visible to the cap at all.

Storm coalescing: one incident, one card

A rollout goes wrong and six policies fire in four minutes. That is one incident, and Nodrik treats it as one: the first alert opens an investigation and the rest fold into it. The card gains the count, the thread gains a line when a genuinely new signal arrives, and your channel gains one message instead of six.

It counts once against your plan, too. Coalescing is not only a noise control; it is the reason a storm does not cost what a storm looks like.

Alerts fold two ways, strongest match first:

• The same cause re-firing. Identity here is the policy plus the resource, with the labels that change per deploy or per instance stripped out — the revision name, the pod, the instance, the task. A flapping policy on checkout-api is the same problem whether or not a new revision happened to be serving when it fired, and treating the revision as part of the identity used to produce a duplicate card after every deploy.
• A different signal in the same incident. A different policy or service, in the same monitored project, inside a tighter window, folds in as a related signal — because one root cause should yield one card. This correlates only inside a known project: prod and staging never merge into one investigation.

Both windows are deployment settings rather than published promises, so this page does not quote them; the related-signal window is the shorter of the two. What is worth knowing is the shape: folding is bounded by how recently the investigation was opened, not by how long the storm lasts, so a policy that keeps flapping across hours eventually opens a second card. That is the case a mute is for.

An investigation that has already failed never accepts folds — it has given up, and later alerts deserve a fresh look rather than an answer that already ran out of road.

The deliberate trade: two genuinely unrelated incidents in one project, minutes apart, will merge into one card. That is the safer error. Every folded alert stays visible in the thread and in the evidence Nodrik reads, so nothing is lost — whereas six cards for one cause is precisely the saturation the product exists to remove.

You can always see the fold. The card’s context line carries the running count — “6 alerts · 2 policies” — and the console’s history has an Alerts column giving how many alerts each investigation is made of. That number is what explains the difference between what Cloud Monitoring recorded and what your channel received.

Muting a cause you already understand

A mute is the one thing in the product that makes Nodrik deliberately quiet. It exists for the case coalescing cannot solve: a known, understood, flapping cause that will keep opening new investigations for hours, where the only other lever is unpointing the policy at Nodrik — which turns the product off for that project, permanently, because nobody remembers to turn it back on.

A mute silences a cause, not a project. It is keyed on the same policy-plus-resource identity coalescing uses, so muting “checkout 5xx on checkout-api” silences that family and nothing else. The database falling over ten minutes later still opens a card. That distinction is the whole value: staying loud about what you have not understood while quietening what you have.

Nothing changes in your own alert policies. Muting is Nodrik-side state about Nodrik’s own cards. Your policies keep firing, keep notifying whatever else they notify, and are yours to silence at source if that is what you actually want.

Pressing it

From the card in Slack, or from the investigation in the console — both land on the same decision, so the two surfaces cannot disagree. The durations are a fixed menu of three: 2 hours, 24 hours or 7 days. The shortest is a one-click button on the card and all three are in the overflow beside it; a duration that is not on the list is refused rather than rounded to one that is.

A mute can be pressed from any state, including on an investigation somebody has already resolved — a cause outlives the card that reported it, and a mute is a statement about the next alert in the family.

Anyone who can click in your Slack channel can press it. Slack has no notion of your Nodrik roles, so the channel is the boundary there. In the console the same action needs at least member access; a read-only user can see what is muted and change nothing. The full table is on Your team.

While it is on

Alerts in that family are counted, not investigated: no card, no thread note, no model call, and nothing against your allowance. The count is the point — it is what lets the end of the mute answer the only question a reader actually has afterwards.

If Nodrik cannot read its own mutes, it investigates anyway. A mute we cannot confirm is a silence we cannot justify: investigating something somebody muted costs one card, and swallowing a real incident because a database hiccuped costs an incident.

When it ends

Mutes expire on their own; nothing has to be remembered. An hourly sweep ends the ones that have run out and posts one line into the original card’s thread — how long it was muted, and how many alerts folded meanwhile.

A mute that swallowed nothing says nothing at all. Announcing every expiry would be the saturation the mute was pressed to stop, arriving late.

Ending one early

Settings ▸ Muted families lists everything currently quiet: what the cause is in words rather than as an internal key, when it ends, who muted it, how many alerts it has folded so far, and a link to the investigation it was pressed on. Unmute ends it immediately.

That list exists because a silence nobody can see the end of is indistinguishable from a broken product. If Nodrik has gone quiet about something and you cannot think why, it is the first place to look — and “Nothing is muted” is a real answer there, never an empty list standing in for a failed lookup.

Or the card never reached Slack

The last possibility is that the investigation ran, the report exists, and Slack did not get it. A delivery failure never fails an investigation, so the report is saved and readable in the console either way. The most common cause is Nodrik having been removed from the channel after the initial connection — see If a report does not show up.

That is also the case that tells the two situations apart: if the report is in the console’s history, the investigation happened and Slack is the problem. If it is not there at all, one of the gates above declined it.