Eight new connectors. One investigation.

An order is stuck. The application logged a timeout. There is work sitting in a queue. The database still says pending.

You open the cloud console, check the broker, run a query, then try to connect what you found. Each system can answer a different question. You still have to put the investigation together.

Horus v0.23.0 brings more of that evidence into one report. We have added eight read-only connectors across cloud logs, metrics, queues and database state.

Eight new ways to bring the evidence in

The new connectors cover four questions that come up repeatedly during an incident:

• What did the application log? Azure Monitor, AWS CloudWatch Logs and Google Cloud Logging bring cloud log entries into the investigation using your configured local vendor CLI access.
• What changed in the metrics? Prometheus reads your configured PromQL queries, adding time-series evidence when Grafana is not configured.
• What is happening in the queue? Azure Service Bus reads queue counts. Kafka reads topic and consumer-group offsets. Neither consumes messages or commits offsets.
• What state was saved? Firestore and SQL Server read counts and configured status/date summaries from allowlisted collections or tables.

These extend the same engine and the same horus investigate command. Add the connectors relevant to your project, and their observations join the evidence from your existing providers and source intelligence.

A better starting point for the next check

Consider an order-processing incident. A timeout tells you a request failed. A growing backlog tells you work is accumulating. A state summary tells you which orders are still waiting. Source context can show where the consumer lives.

Together, those observations give you a more specific place to investigate: the consumer, its recent changes, and whether it is keeping up with the queue. Each observation remains inspectable in the report.

A queue count cannot explain a failure on its own. Horus keeps the distinction visible: evidence describes what was observed, a ranked hypothesis proposes an explanation, and the next check tells you how to test it.

Built to inspect the systems you already run

The cloud log connectors reuse your configured Azure, AWS and Google Cloud CLI credentials. Other connectors use the endpoints and credentials you select during setup. Choose the project, log groups, queues, topics and data allowlists that belong in the investigation.

Broker collection stays at counts and offsets. Database collection stays at bounded summaries rather than whole records. For SQL Server, use a SELECT-only login; read-only connection intent alone does not restrict permissions. Reads can still incur normal provider costs and database load.

Connect it to your next investigation

Install v0.23.0, initialize your repository if needed, then add a connector:

npm install -g @merittdev/horus@0.23.0
horus --version

# Inside your repository
horus init
horus connect cloudwatch
horus investigate "orders waiting"

Choose azure-monitor, cloudwatch, gcp-logging, prometheus, azure-service-bus, kafka, firestore or sqlserver with horus connect. Follow the prompts to configure access and scope, then add any other sources that matter for the project.

The release is also available through Homebrew and the Horus installer. See the installation guide, changelog and v0.23.0 release.

The same investigation, with more of the story

The useful outcome is a report that connects what your systems observed to a concrete next check. With these eight connectors, more of your existing stack can contribute to that report.

Start with the source you usually have to open in another tab. Connect it once, then bring its evidence into the next investigation.