How monitoring works

Umbra watches each monitored domain against a reputation feed, a corpus of credential data circulating in breach dumps, combolists and infostealer logs. Everything on the entity screens comes from that feed. This page covers how a record reaches the console and how to read what it says once it is there.

Two kinds of record

The distinction runs through every screen, because the two answer different questions.

• Breach and combolist records. A credential that surfaced in a dump from a breached service, or in an aggregated list assembled from several. The exposed service is the thing to fix.
• Infostealer captures. A credential taken off a machine by malware and traded on. The capture implicates the machine as much as the account, so it carries a device behind it and everything else that machine leaked.

From detection to alert

1. A domain is registered for monitoring.
2. The reputation feed detects a record for that domain and pushes it to Umbra.
3. Umbra stores it once. A record already held is not stored again, so a repeated push changes nothing.
4. A genuinely new record adds an entry to the bell and to the Alerts feed the moment it arrives, and is queued for whichever destinations the notification rules route it to.
5. Email and Slack are delivered as one grouped message per organization, covering everything queued since the last one. A sweep runs every two minutes, so a single detection in a quiet week goes out on the next sweep, and only a burst waits for the cooldown between messages. Webhook destinations still receive one request per record, immediately, because the code consuming them expects one request per event.
6. The record joins Exposures and the entity screens for its domain.

A first registration imports nothing: the domain's history is not replayed as alerts. It is browsed live from the feed on the Exposures and entity screens, and alerts start from the registration. Registering the same domain again catches up any alerts the console has not stored yet, and reports them once, as a single Alerts caught up summary rather than one alert per record.

Two dates that mean different things

Exposure records carry two timestamps and both appear in the console.

• Captured is when the credential was taken, or the date the breached data is from.
• Detected is when the reputation feed found the record and indexed it.

A credential captured a year ago can be detected today, on the day its stealer log finally surfaced. A fresh detection of an old capture is still news, and finding that out is what monitoring is for.

Freshness elsewhere in the console follows the capture date rather than the detection. The New alerts (30d, by record date) column on the Domains screen and the freshness filter on Exposures both count records captured inside the last 30 days. A record with no date at all counts as historic. The one exception is the 30-day figure on Exposures (the Free plan's teaser, and the line in the header on Pro), which counts the records the feed added (detected) in the last 30 days.

How much is loaded at once

The feed paginates forward only, so a screen holds a batch rather than the whole domain. One batch is up to 200 breach records plus up to 200 infostealer captures, and Load more folds the next batch into what is already on screen. Loading a deeper batch is always an explicit action. Nothing loads more on scroll, because each batch is a real round trip to the feed.

Exposures pages its loaded records with a numbered pager, labelled Page N of M loaded while the feed holds more. Next walks only the loaded pages: on the last one it stops, and so does Next on a record page at the last loaded record. The next batch comes from the same Load more the other screens carry, above the table. The footer under the table compares like with like: 12 matching of 225 loaded while a search or filter narrows the rows, and 225 loaded of 1,940 in the feed when nothing does. A lookup of one exact address has no Load more, because the feed's answer for that address is already whole.

Showing N of M states the size of that batch against the feed's own total for the domain, which is why the headline totals are exact while only part of the records are held. Next to it the console states the batch's mix, for example 200 infostealer, 140 breach. Because each batch takes one page from each index, that mix describes what is loaded, not the domain: a domain with thousands of breach records and a few hundred infostealer captures still loads up to 200 of each. On a domain you have verified, the batch also holds the captures made on your own sites, so their total is named beside the domain's (+ 395 captured on your sites) rather than added to it.

The loaded records are cached for 20 minutes per domain, which is what makes moving between Overview, Identities, Exposures, Devices, Sources and Services immediate rather than a fresh read each time. Those screens share the one batch, so a Load more on any of them shows on all of them. Every screen served that way carries Updated N ago next to a Refresh button, so the age of what is on screen is visible and can be overridden.

Counters are exact, or carry a plus

A counter that comes from a figure the feed reports is exact. A counter derived from a list the feed caps shows the highest number actually seen with a trailing plus. An identity's risk posture lists at most 100 records, so 100+ means at least 100 rather than exactly 100. A counter with no plus is a real total, unless the batch is flagged as partial (see Partial batches).

Coverage is uneven, and says so

The feed's coverage differs by kind of record, which produces answers that look incomplete but are accurate.

• An infection can be reported with no captured credentials behind it yet. The device screen then reports an infection with metadata only, giving the dates and identifiers it does have, rather than claiming the machine is unknown.
• Captured credentials can exist with no machine details behind them. The screen says so in place of the dossier.
• Coverage grows over time. An infection reported with nothing behind it can gain its captures later.

Umbra keeps "nothing found" and "not known" apart everywhere. An empty screen means the feed holds nothing, never that a lookup failed.

Partial batches

The feed is occasionally slow for a large domain, and a first load can take up to 30 seconds while Umbra waits for its answer. The loading message says so; there is no need to reload, which only starts the same wait again. When the feed runs past the time budget, or one part of it fails to answer, the rows already retrieved are returned and the batch is flagged rather than the whole request failing. Exposures reports that the batch is partial and, while the Load more above the table is showing, points at it to continue; Load more asks again for any part that did not answer. The rows shown are real. There are simply more behind them. A count from a part that did not answer is not known yet, so it shows as — rather than 0, and the total it belongs to shows with a + until that part answers. A part that sent records without saying how many it holds counts the records it sent, and the batch stays flagged as partial while that part has more to load. A breach count of 0 always means the feed answered and holds no breach records.

What the free plan changes

On the Free plan, records captured or detected within the last 30 days are withheld, so the detail arrives 30 days after the later of the two. The counts that include those records are not withheld, so the number of recent findings stays visible even while the rows behind it are not. Password fragments are masked. Device details and infection identifiers come back hidden, which is what stops an investigation pivoting from a credential to the machine that leaked it. No alert is dispatched to a notification destination at all.

Identities and email addresses are readable on every plan, and so are breach and source names. The console reports what it is withholding rather than hiding the fact. See Plans and billing for the full comparison.