Frequently Asked Questions

Push raw data at us - a handful of sources you're already collecting, straight from the source or through whatever you already run.

Nothing to install, nothing to filter, nothing to map. We do the rest.

Because we read your data once, instead of once for every detection you run with traditional store and query based systems.

Solutions built on scheduled search keep everything in hot, indexed storage, then runs each of your detections as its own search across it. Every search you add costs another pass over the same data — which is why there’s a ceiling, and why most teams stop somewhere around a hundred.

We read it once, as it arrives, and every detection you have rides along in that single pass. Adding another doesn’t make us re-read anything, so the ceiling disappears — we run thousands concurrently, and what you run is decided by your data rather than your budget.

That one difference is where the rest comes from. What you pay scales with how much you send, not with how many detections you run or how often. There’s no next run to wait for. And a detection can hold state while the data is still moving, rather than rebuilding it from a query afterwards.

And spotr.io is one product — detection, investigation and containment, with nothing for you to wire together.

Storage genuinely does get cheaper, and if storage is your problem that's a reasonable move.

But detection on a lake is still querying, and queries are metered. Run them continuously and the compute doesn't nibble at the edges - it rivals the bill you just walked away from. You don't escape the SIEM spend, you change which department pays it.

And treat "free analysis" carefully. The analysis is free; the compute that performs it isn't. Detection at real volume means scaling the platform underneath you, and that upgrade shows up as infrastructure rather than security - which is precisely why it looks like a saving.

And the ceiling doesn't move. What limited how many detections you could run was never the price of storage, it was the cost of searching. A lake leaves that exactly where it was, and hands you the job of building detection on top of it.

Because nothing is handed off. The data is enriched as it arrives, so when a detection fires the context an investigation needs is already attached - nothing has to be fetched back from other systems.

Then it goes through three stages, each more thorough than the last. Known-benign and already-seen stop at the learning engine in milliseconds. Most of the rest is settled by the decision engine against evidence and history. Only what survives reaches the AI SOC Analyst. And the containment actions are already wired, so acting on a conclusion isn't a ticket into another tool.

An AI layer bolted onto a SIEM or a lake works the other way round. It receives an alert with no context, so it has to go and ask - every round trip a query against someone else's store, plus raw results loaded into a model.

That cost doesn't go away, it moves. Query compute on your cloud bill, tokens on someone's platform spend, neither traced back to the security decision that caused it. Worth asking of anything you're considering: whose invoice does this show up on?

We show you the clock for every step: when the event was generated, when we received it, enriched, detected, qualified, investigated, contained. We can time the whole thing because we run the whole thing.

That first gap is worth watching. Some sources are notoriously slow to deliver, and nothing downstream can make up a delay that happened before the data arrived - but you should know which of yours do it.

Ask your current tooling for the same breakdown. Usually it can't produce one: the clock runs across four products, nobody owns the timestamps end to end, and plenty of tools don't keep the generation time at all. Where it can, the honest version is unflattering - the biggest segment is the wait between scheduled runs, which is time when nothing is looking.

Keep anything that generates data - your EDR, your cloud logs, an NDR if it's on-prem and tapping traffic directly. Those are sensors, and we want what they produce. A cloud NDR usually works from flow logs you could send us yourself, so that one goes in the other pile.

We take their raw output directly, which is what makes the tooling in between redundant. An XDR covers the sources its vendor bundles. Anything needing more than a single event - a sequence, a correlation, a baseline - goes back to the SIEM, where complexity costs compute: the harder the detection, the fewer you can run and the less often. Here there's no handoff, and complexity costs nothing extra.

The SIEM depends on what you use it for. If it's detection, you'll need a lot less of it - or none, if that's all you're using it for. If it's the glue holding workflows and reporting together, it isn't going anywhere soon, and we don't need it gone to give you coverage.

Yes - and you won't be starting from scratch. Our library is already running against whatever you send, matched to your data rather than handed to you as a catalog to pick through.

When you want something specific, describe it in plain language and our detection engineering agent builds it. It's tested against your recent data before it goes live, so you see how it behaves before it starts firing at you.

Every detection is declared - you configure it, or we do. The difference is what it compares against. Some compare against something specified: a pattern, a sequence of steps. Others compare against a baseline learned from your own data - what's normal for this account, this host, this service.

Both are inspectable. Neither is a mystery score.

And a detection firing isn't something landing on your desk. The decision engine weighs it first, and only what warrants investigation gets one.

They come with you. Sigma and Elastic rules translate straight across. Anything else you've built, bring it along and we'll add it in.

Run yours alongside ours for as long as you like, then start adding the detections you couldn't run before.

It's easy — and we do not need your credentials.

Push data directly from your cloud environments (AWS, GCP, Azure), CDN logs, identity events, and EDR telemetry. Already using a pipeline tool like Cribl or Vector? Just point a route our way. You can also forward streams straight from your SIEM or data lake.

No agents to install. No credentials to share. Just connect and detect.

Simple: one rate based on daily ingest volume, regardless of source. Windows event logs, cloud telemetry, CDN logs— it all counts the same. Unlimited concurrent detections are included. No per-detection fees, no surprise line items, no "call us to find out" games. Just predictable pricing that scales with your data.

Both options are available. Annual and multi-year commitments get you the best pricing, but we also offer pay-as-you-go if you want flexibility. No lock-in required to get started — use what you need, scale when you're ready.

Nope. Setup is free and fast — there's no professional services engagement, no lengthy onboarding project, and no hidden implementation fees. Connect your data sources, and you're detecting.

spotr.io is a streaming detection engine — we process your data in real time and don't require a data warehouse to operate. By default, data is evaluated on stream and doesn't persist after processing. If you need long-term retention for compliance or investigation, spotr.io can sink your data to S3, Snowflake, or your preferred data lake (s). You choose what's stored, where it goes, and how long it's kept. Your data, your choice.

Absolutely. Security isn't just what we sell — it's how we operate. All data is encrypted in transit and at rest. Your data streams are processed in isolated, single-tenant environments and are never shared across customers. Access is tightly controlled, audited, and limited to the minimum required to operate the service.

We're currently pursuing SOC 2 Type II certification. Our platform is built from the ground up with security-first architecture, including encryption, access controls, audit logging, and data isolation. If you have specific compliance requirements, reach out — we're happy to walk through our security posture in detail.