Monitors allow you to track specific metrics or calculate SLOs, while SLOs help you define performance targets and evaluate how well your system meets those targets.
What are SLOs?
SLO, or Service Level Objective, is a key concept in the realm of observability, which is the practice of monitoring, understanding, and optimizing the performance and reliability of software systems. To break it down, let's define each term separately:
  • Service: A software application or system that delivers functionality to users or other systems.
  • Level: A measure of quality or performance.
  • Objective: A specific, measurable target that a service aims to achieve.
In the context of observability, SLOs are typically expressed as a percentage or a ratio, representing the desired level of performance over a given time period. These targets are usually defined in terms of key performance indicators (KPIs), such as response time, error rate, or availability. By monitoring these KPIs, teams can assess whether the service is meeting its objectives or if there is a need for improvement.

Building monitors

To build monitors, you can leverage blocktorch's powerful query engine, which allows you to query various types of data, such as chains, blocks, transactions, and gas fees. All available faucets can are listed here. By using blocktorch's query chips you can create complex queries and filters to focus on the desired aspects of your data, enabling you to build accurate and relevant monitors.
To build a new monitor navigate to the "Monitor" overview page in the blocktorch app and click the "+ Add Monitor" button in the top right.

1. event based vs metric based monitors

An event based monitor is the ratio of the specific queried KPI compared to the total number of events. Also called a Service Level Objective.
For example: the count of transactions with a specific characteristic (e.g. REVERTED transactions) divided by all transactions.
Building an event based monitor in Blocktorch
A metric based monitor is purely monitoring a specified KPI.
For example: the total sum of gas units used

2. building the queries

  • All query faucets can be combined and mixed as you wish. The full list of available faucets and operators can be found here.
  • To finish the query choose to get the SUM, the COUNT or the AVERAGE of your metric, as well as the Smart Contract.
want to build monitors across smart contracts and also across different blockchains? Please reach out.

3. Choose a window for monitoring this query on a rolling basis.

Time windows for the monitors to check the query on

4. Choose a target you want to achieve.

For an event based monitor the target always is a %.
For example: not more than 2% of transactions should revert (=> 98% success rate of transactions)
For a metric based monitor the unit of the target depends on the metric to be monitored.
For example: when monitoring gas the target is in gas units, when monitoring balances the target is in the unit of the balance to monitor

5. Add a title and description

The title will display in the monitor chart as soon as you saved the monitor
The description will help you and teammembers in the project to understand the rational behind the monitor also the future to

5. Save the monitor on the top right

Last modified 23d ago