Choosing an LSST Alert Broker: A Workflow Guide for Rubin Observatory Alerts

Bottom Line

If you already understand the basic Rubin Observatory alert-stream story, the next decision is more practical: which broker interface will let you find, filter, and route the candidates you actually care about?

Rubin Observatory’s first science alerts began streaming in February 2026, according to the observatory’s first-alert announcement. That milestone does not make every LSST-era workflow mature. It does make broker selection a real software decision: browser or code, Python or SQL, watchlist or substream, manual inspection or automated handoff.

This is not a ranking of ALeRCE, ANTARES, Fink, and Lasair. Rubin lists all four as full-stream community brokers. The useful question is narrower: which broker exposes the alert stream in the shape your workflow can maintain?

What This Guide Is Narrowing

Recent Rubin coverage often explains what an alert packet is, whether an alert is the same thing as a discovery, or how early Rubin milestones relate to later data products. That background matters, but it is not the focus here.

This guide starts one layer later. It assumes the alert exists and asks what happens next: which software layer enriches it, filters it, crossmatches it, stores it, exposes it through an interface, and sends it toward a person, script, classroom activity, or follow-up system.

That distinction matters because two users can care about the same sky event and still need different broker behavior. A student inspecting light curves, an educator building a lab exercise, and a follow-up network triaging candidates are not choosing the same tool for the same reason.

Evidence Level

The source base is official Rubin Observatory material: the alerts-and-brokers documentation, the February 2026 first-alert announcement, and Rubin’s Early Science Program page.

Those sources support a broker-selection guide, not a claim that every Rubin data product, alert workflow, or downstream service is fully settled. First alerts, Early Science activity, and Prompt Products belong to the same rollout, but they are separate milestones.

Broker Choice By Workflow Fit

Rubin’s broker page lists full-stream community brokers and points readers toward broker-specific resources. The table below focuses on four common choices: ALeRCE, ANTARES, Fink, and Lasair.

Broker	Status in Rubin documentation	Workflow signal to check first	Prefer it when your bottleneck is…
ALeRCE	Full-stream broker	Classification, light-curve catalog context, annotated objects, watchlists, web/API access	Sorting candidates by likely object class and inspecting context before writing much custom logic
ANTARES	Full-stream broker	Python filters, watchlists, APIs, catalogs, notifications, alert substreams	Encoding custom selection logic and turning it into a repeatable monitoring workflow
Fink	Full-stream broker	Modular science modules, stream processing, APIs, Kafka-oriented access, personalized filters	Connecting broker output to an automated or semi-automated analysis pipeline
Lasair	Full-stream broker	SQL-style filters, crossmatches, light-curve features, machine-readable output	Expressing selection rules as queries and combining alert context with catalog or light-curve features

The table should be read as a workflow map, not a verdict.

If your first task is to look at likely object classes and light-curve context, ALeRCE may be the most natural place to inspect first. If your team thinks in Python and wants custom rules, ANTARES deserves close reading. If you need stream-oriented integration, Fink is the broker to study carefully. If your selection logic feels like a database query with catalog joins and crossmatches, Lasair may be the cleaner starting point.

The Interface Decision Comes First

A browser interface is not a beginner-only feature. It is useful when you need to see whether the broker’s context, classifications, and examples match the science question before committing to code.

Python filters are useful when the rule is procedural: compute something, branch on several conditions, and reuse the logic. They are also easier to fit into many research notebooks and small scripts.

SQL-style filters are useful when the rule is relational: select objects with certain properties, combine alert features with catalog context, and revise the query as the target definition changes.

APIs matter when the workflow must run again without manual clicking. Kafka streams and broker-provided substreams matter when the selected candidates need to move into another service or pipeline as data, not as a web page someone remembers to check.

Watchlists sit in a different category. They are useful when the question is not “what is new tonight?” but “did something happen to the objects or regions I already care about?” For monitoring workflows, that distinction can be the difference between a manageable feed and an inbox full of noise.

A Concrete Scenario: The Fast-Transient Student

Imagine a graduate student helping with a small follow-up program for fast transients. Telescope time is scarce, and the useful candidates may not wait politely for the next morning’s inspection.

I would slow down at three points before choosing a broker.

First, define the candidate shape. Is the student looking for a broad class of young supernova candidates, unusual variables, or a narrower transient signature? If classification and light-curve summaries are the first need, ALeRCE is worth opening early.

Second, define the filter language. If the rule is easiest to express as Python, ANTARES may fit. If it is easier as a SQL-style query with crossmatches and light-curve features, Lasair may be more direct.

Third, define the handoff. If the filtered stream has to feed a larger automated pipeline, Fink’s API and Kafka-oriented access may matter more than a polished first browser view.

The easy mistake is to ask which broker is most powerful. A sharper question is which broker makes the next failure visible: a bad filter, missing catalog context, a noisy substream, or a follow-up step that never receives the candidate.

Where Classroom And Public Inspection Fit

Not every Rubin alert workflow is a production pipeline. An instructor may want students to inspect candidate context in a browser, compare light curves, and learn why a classification is tentative.

For that use case, the best broker is not necessarily the one with the most automation hooks. It is the one whose interface, examples, and documentation let students move from candidate to context without pretending the browser view is the final scientific answer.

That is also a useful test for advanced users. If a broker’s web view makes the data model legible, it can speed up debugging even when the final workflow runs through an API.

Full-Stream Versus Downstream Brokers

Full-stream brokers receive and process Rubin alert streams at scale. Downstream brokers or tools can take broker outputs and specialize them for narrower use cases.

That distinction should affect where you start. If your workflow needs broad alert access, begin with the full-stream broker documentation. If your workflow depends on a specialized candidate class, a follow-up network, or a domain-specific view, a downstream tool may be the better layer to evaluate.

The safest sequence is usually full-stream broker first, downstream service second. That keeps you from mistaking a specialized interface for the whole alert ecosystem.

What To Watch Next

The next useful Rubin updates will not simply say that more alerts exist. For broker selection, the useful updates are documentation examples, working filters, Prompt Products context, downstream routing, and evidence that early users can reproduce a workflow from alert packet to candidate handoff.

A practical first test is deliberately small: choose one candidate type, open two broker interfaces, and trace the same kind of alert from packet context to filter result to watchlist, substream, or follow-up handoff.

That exercise exposes the real decision point in LSST-era discovery. The telescope starts the alert. The broker determines whether the right person, script, or classroom sees it in time.

Sources

The main source trail for this guide is Rubin Observatory’s alerts-and-brokers documentation, which is also the best starting point for direct broker links and broker-specific documentation.

For timing and rollout context, use Rubin’s first-alert announcement and the Early Science Program page.