Crypto Trading Bot Monitoring: 11 Metrics, Alerts & Failure Checks (2026)
Crypto trading bot monitoring is the operating layer that proves a live bot is receiving fresh data, submitting the orders it intended, recording the fills the exchange produced, and escalating failures to a human who can act. This guide provides 11 critical signals, a deterministic health triage tool, an order-reconciliation model, an alert severity matrix, and a restart runbook.
Last fact-checked: September 22, 2026 · Educational content for U.S. readers · No profit, uptime, or loss-limit guarantee
Coinrule provides rules-based automation and a demo exchange workflow. Use simulated execution to test rule behavior, notification paths, and your monitoring checklist before connecting live capital.
What Crypto Trading Bot Monitoring Must Prove
A strategy decides whether a trade should exist. Risk controls decide how much exposure is permitted. Crypto trading bot monitoring answers a third question: is the live system still behaving as designed? Keeping those roles separate prevents a dashboard from becoming a confused mixture of P&L, infrastructure status, and strategy opinions.
Google’s Site Reliability Engineering guidance defines monitoring as collecting, processing, aggregating, and displaying quantitative system data. Its four “golden signals”—latency, traffic, errors, and saturation—translate cleanly to bot operations. For a trading system, add two non-negotiable dimensions: data freshness and state correctness. Low latency is irrelevant if the bot is fast on stale prices or holds a position its database does not know about.
| Layer | Question | Evidence | Failure a green badge can miss |
|---|---|---|---|
| Process | Is the expected instance alive? | Heartbeat, version, uptime, last completed cycle | The process runs but its worker loop is stuck |
| Data | Is every required input fresh and ordered? | Event time, receive time, sequence gaps, source | A live socket repeats an old book snapshot |
| Decision | Did the strategy evaluate the expected universe? | Signal count, reason code, config hash | A filter silently removes every symbol |
| Execution | Did the venue accept and fill the intended order? | Client ID, exchange ID, status events, fills | A timeout is treated as a failed order and retried |
| Account | Do internal and exchange records agree? | Orders, positions, balances, fees, timestamps | An external/manual trade creates position drift |
| Response | Can the operator receive and act on an alert? | Delivery test, acknowledgement, runbook, owner | The alert fires into a muted or expired channel |
A practical crypto trading bot monitoring baseline therefore combines infrastructure telemetry with exchange-confirmed trading state. Neither side is sufficient alone: application metrics explain how the bot behaved, while venue records confirm what actually happened to the account.
This page intentionally does not repeat position sizing, portfolio limits, or drawdown design. Use the dedicated crypto trading bot risk management framework for those controls, the API security guide for credential design, and this page for live observability and incident detection.
Crypto Trading Bot Monitoring Health Triage
This interactive crypto trading bot monitoring triage converts six observations into one conservative operating state. The thresholds are yours: enter the limits already approved for the bot and venue. The logic does not average away critical failures. Any unmatched order or position mismatch produces an incident state even if every other metric looks healthy.
Educational decision aid—not an exchange command, safety guarantee, or universal threshold. “Position mismatch” means the difference between the bot’s expected position and exchange-confirmed state. Define a documented tolerance for rounding and dust rather than entering an arbitrary number.
Manual rule: an orphan order or material position mismatch is an incident; stale heartbeat or stale market data should block new entries; elevated API errors or failed alert delivery indicate degraded monitoring.
The hierarchy is deliberate. A weighted score can label a bot “mostly healthy” while it holds an unknown position. In operational crypto trading bot monitoring, correctness failures outrank performance averages. The result tells you where to begin; the exchange account, raw events, and written runbook remain the sources for the actual response. Use crypto trading bot monitoring thresholds derived from the actual strategy clock and venue behavior, then retest them after material changes.
11 Critical Crypto Trading Bot Monitoring Signals
No universal threshold is safe for every strategy. A market-making process and a four-hour trend strategy operate on different clocks. For each crypto trading bot monitoring signal below, define the measurement, normal baseline, warning condition, critical condition, automated action, owner, and evidence required to clear the alert.
Signal 1Crypto Trading Bot Monitoring: Process Heartbeat
A process heartbeat proves that the expected instance is emitting on schedule. Include the bot ID, deployment version, strategy version, environment, last completed loop, and monotonic sequence number. A basic “server reachable” check is weaker because the host can answer while the trading worker is deadlocked.
Monitor both missing heartbeats and improbable activity. A bot that restarts every few minutes may keep emitting “alive” events while continuously losing in-memory state. Alert on restart count, crash loops, and a last-success timestamp for the work that actually matters.
Signal 2Crypto Trading Bot Monitoring: Market-Data Freshness
Record the exchange event time and local receive time. Their difference helps separate venue delay from local processing delay. Check sequence numbers or update IDs where the feed provides them; reconnect when the protocol requires it, rebuild the book from the documented snapshot procedure, and refuse to trade until continuity is restored.
“Price changed recently” is not a freshness test. Quiet markets can be valid. Instead, compare message age, expected cadence, stream status, and sequence continuity. Cross-checking a second source can support diagnosis, but the bot must know which source controls execution.
Signal 3Crypto Trading Bot Monitoring: Exchange Session Health
Track authenticated stream status, reconnect attempts, subscription confirmation, clock synchronization, DNS/network failures, and the age of the last account event. A public price feed can remain healthy while the private user stream has expired or unsubscribed, leaving the bot blind to fills.
For every venue, document session renewal and reconnection behavior. Binance’s official User Data Stream documentation, for example, exposes subscription status and account events. The implementation details vary, so treat each exchange adapter as its own monitored dependency.
Crypto trading bot monitoring should also detect a split-brain condition in which public market data is healthy but authenticated account data is silent.
Signal 4Crypto Trading Bot Monitoring: API Latency, Errors, and Rate Budget
Measure request latency by endpoint and outcome rather than one global average. Track success, client errors, server errors, timeouts, exchange error codes, request weight, order-count limits, and backoff behavior. Use percentiles as well as medians so brief but consequential tails are visible.
Do not automatically classify a timeout or server error as “order failed.” Binance explicitly documents that some timeouts and 5XX responses leave execution status unknown. The correct next action is to check the user stream or query order state—not blindly submit a duplicate. Rate-limit responses also require backoff; repeated violations can escalate the outage.
Signal 5Crypto Trading Bot Monitoring: Signal-to-Acknowledgement Latency
Attach timestamps to signal creation, risk approval, request submission, exchange acknowledgement, first fill, and final fill. This decomposes latency into strategy, network, venue, and liquidity stages. The relevant budget depends on the strategy horizon; compare live distributions with the assumptions used during testing.
A single fast acknowledgement does not prove execution quality. Compare latency by symbol, order type, time of day, market regime, and exchange. A rising tail may reveal an overloaded worker, rate-limit pressure, or venue degradation before the error count increases.
Signal 6Crypto Trading Bot Monitoring: Rejects, Partial Fills, and Cancellations
Track outcomes as rates with denominators: rejected orders divided by attempted orders, partial fills divided by acknowledged orders, and cancel failures divided by cancel requests. Preserve the exchange reason code and human-readable message. Raw counts are misleading when trading activity changes.
Segment by symbol and rule. Minimum notional, precision, insufficient balance, invalid timestamp, post-only rejection, and price-band violations require different fixes. Partial fills are not inherently failures, but the remaining quantity, protection logic, fee treatment, and final position must be explicit.
In crypto trading bot monitoring, the denominator and time window belong beside every rate so an operator can distinguish one isolated reject from a systematic execution problem.
Signal 7Crypto Trading Bot Monitoring: Order-State Reconciliation
Every order should move through a known state machine. Compare intended, submitted, acknowledged, open, partially filled, filled, canceled, expired, and rejected states using a client-generated correlation ID and the exchange order ID. Flag an order when the bot and venue disagree or when no terminal state arrives inside the approved window.
An “orphan” can be an exchange order absent from the bot, or a local order record with no exchange confirmation. Both require investigation before new risk is added. Never infer the absence of an order solely from a missing response; query the venue and inspect account events.
Signal 8Crypto Trading Bot Monitoring: Position and Balance Reconciliation
Poll or stream exchange-confirmed balances and positions, then compare them with the bot’s internal ledger. Include free, locked, borrowed, and collateral amounts where relevant. Apply documented tolerances only for known rounding and dust—not to hide unexplained differences.
A mismatch can come from a partial fill, fee asset, manual trade, transfer, liquidation event, another bot, or a missed account event. Freeze the affected automation until the ownership of every unit is known. For leveraged products, include margin mode, side, entry price, and liquidation-related fields exposed by the venue.
Signal 9Crypto Trading Bot Monitoring: Slippage, Spread, and Fee Drift
Compare expected execution with actual fills using a consistent benchmark—such as decision-time midprice, quoted price, or arrival price—and record the method. Measure spread, realized slippage, fee rate, funding or borrow costs when applicable, and market impact. Review distributions, not one favorable average.
Thresholds should follow the strategy’s tested edge and live baseline. A small numeric change can matter to a high-turnover system and be irrelevant to a slower strategy. When execution cost drifts, diagnose liquidity, order type, size, latency, and venue before changing the trading logic.
Crypto trading bot monitoring should preserve both the benchmark price and the chosen calculation method so slippage comparisons remain reproducible.
Signal 10Crypto Trading Bot Monitoring: Activity and Configuration Drift
Watch for too many signals, too few signals, unexpected symbols, duplicated cycles, abnormal order frequency, and long periods with no completed evaluation. Compare activity with a time-of-day and market-regime baseline rather than an arbitrary universal count.
Log a hash of the active configuration and strategy version with every decision. Alert when the running version differs from the approved deployment, when environment variables change, or when a platform-side override changes behavior. Configuration history is part of the incident timeline.
Signal 11Crypto Trading Bot Monitoring: Alert Delivery and Acknowledgement
A rule that fires but reaches nobody is not a control. Send test alerts on a schedule, monitor the notification integration itself, record delivery and acknowledgement, and provide a secondary route for critical incidents. The message should include bot, venue, symbol, state, first observed time, current impact, immediate action, and a runbook link.
Prometheus guidance recommends keeping alerts simple, alerting on symptoms, and avoiding pages where there is no action. Apply that discipline: informational events belong in a dashboard or digest; only urgent, actionable conditions should interrupt a human.
Build an Order Lifecycle That Can Be Reconciled
The core artifact in crypto trading bot monitoring is not a chart—it is a traceable order lifecycle. The same correlation ID should follow one decision from signal to final account state. If the exchange supports a client order ID, make it unique and idempotent within the venue’s rules.
→ RISK_APPROVED or RISK_BLOCKED
→ SUBMISSION_STARTED
→ ACKNOWLEDGED or STATUS_UNKNOWN
→ OPEN / PARTIALLY_FILLED / FILLED / CANCELED / EXPIRED / REJECTED
→ FEES_RECORDED
→ POSITION_RECONCILED
→ BALANCE_RECONCILED
→ TERMINAL_EVIDENCE_STORED
| State transition | Required evidence | Timeout action | Never assume |
|---|---|---|---|
| Decision → submission | Signal ID, config hash, intended side/size/price, approval result | Expire the decision or re-evaluate under documented logic | That an old signal remains valid |
| Submission → acknowledgement | Client order ID, request timestamp, exchange response | Mark status unknown and query state | That a timeout means rejection |
| Acknowledgement → fill | Exchange order ID, cumulative quantity, fill events, fees | Apply the strategy’s approved cancel/replace policy | That “open” means untouched |
| Cancel request → terminal state | Cancellation response plus final fill query | Re-query; a fill may race the cancellation | That cancel submission removed exposure |
| Terminal order → ledger | Exchange-confirmed position and balances | Freeze new entries on unexplained mismatch | That local arithmetic is exchange truth |
This state machine turns crypto trading bot monitoring into an auditable chain instead of a collection of disconnected charts.
Crypto Trading Bot Monitoring Alert Severity Matrix
Severity should describe operational impact and required response—not how dramatic the message sounds. Calibrate persistence windows and cooldowns so a brief recoverable spike does not page repeatedly, while correctness failures escalate immediately. The examples below are a design pattern, not prescribed thresholds.
| Severity | Example condition | Automated containment | Human response | Clear condition |
|---|---|---|---|---|
| P1 — Incident | Material position mismatch, orphan order, duplicate order, uncontrolled exposure | Freeze new submissions for affected scope; preserve exit controls | Immediate exchange-side verification and reconciliation | Every order, fill, position, and balance is accounted for |
| P2 — Stop new entries | Stale required data, missing heartbeat, private stream lost, persistent unknown status | Block new risk; continue observation and approved protective logic | Prompt diagnosis using logs and venue state | Fresh streams plus successful reconciliation cycle |
| P3 — Degraded | Rising latency, errors, rejects, partial fills, slippage, or rate-limit usage | Optional size reduction or alerts-only mode if pre-approved | Review trend during staffed window | Metric returns inside baseline for defined duration |
| P4 — Informational | Deploy, configuration change, planned restart, routine alert test | Record event | Review in dashboard or digest | Acknowledged change evidence |
Avoid alerting on every internal cause. One stale-data symptom may be produced by DNS, a disconnected socket, a failed subscription, venue maintenance, or an overloaded worker. Page on the operational impact, then use dashboards and logs to isolate the cause. Group related events so one venue outage does not create hundreds of independent notifications.
Good crypto trading bot monitoring makes every page answer three things immediately: what broke, what was contained, and what the operator must do next.
Dashboard, Logs, and Evidence for Crypto Trading Bot Monitoring
A useful crypto trading bot monitoring dashboard answers “Can the bot trade correctly right now?” in under a minute. Keep the first view small and actionable, then link to detailed panels. P&L can be present, but it should not crowd out state correctness and execution health.
| Panel | Show at a glance | Drill-down |
|---|---|---|
| System health | Heartbeat age, instance/version, restarts, cycle completion | Host/container events and deployment timeline |
| Data and sessions | Feed age, sequence gaps, authenticated stream age, reconnects | Subscription events and source-specific logs |
| Order pipeline | Intended, submitted, acknowledged, open, partial, unknown, terminal | One correlation-ID trace with raw venue events |
| Execution quality | Latency percentiles, rejects, partial fills, slippage, fee drift | Symbol, venue, order type, and time-window segments |
| State correctness | Orphan count, position mismatch, balance mismatch, last reconciliation | Exchange-vs-local ledger comparison |
| Incidents and changes | Open alerts, owner, acknowledgement, config/deploy markers | Runbook, timeline, evidence, recovery approval |
OpenTelemetry defines logs as timestamped records and recommends structured logs in production because a stable schema is easier to validate, correlate, and analyze. For a bot, store consistent fields rather than prose that requires fragile text matching.
deployment_version · strategy_version · config_hash · correlation_id
exchange · account_alias · symbol · market_type
client_order_id · exchange_order_id · intended_action · risk_decision
request_type · response_code · exchange_error_code · order_state
requested_qty · filled_qty · average_fill_price · fee_amount · fee_asset
latency_ms · market_data_age_ms · position_before · position_after
severity · runbook_id · operator_action · recovery_evidence
Consistent field names allow crypto trading bot monitoring queries to follow one order across strategy, risk, adapter, venue, and ledger components without brittle text parsing.
Redact secrets at the source. Do not log API keys, signatures, passphrases, session tokens, raw authorization headers, or private webhook URLs. Restrict access to logs because they can still reveal account structure, strategy logic, identifiers, and trading activity. Retention should match operational, security, tax, and legal requirements applicable to the operator.
Incident Response: From Alert to Controlled Restart
Crypto trading bot monitoring is incomplete without a practiced response. The goal is not to close everything automatically under every failure. An indiscriminate shutdown can cancel protective orders or turn a temporary visibility problem into realized slippage. Define containment by incident type and test it away from live capital. The crypto trading bot monitoring runbook must identify who can pause, reconcile, repair, and authorize a restart.
- Acknowledge and timestamp. Assign one incident owner and record when the condition began, when it was detected, and which bots, accounts, symbols, and venues may be affected.
- Contain new risk. Freeze new entries or submissions in the smallest safe scope. Do not remove approved protective exits unless the runbook explicitly requires it.
- Preserve evidence. Snapshot configuration, version, logs, pending requests, recent account events, current orders, positions, and balances before restarting components.
- Check exchange truth. Use authenticated venue records to verify open orders, recent fills, positions, balances, and any manual or external activity.
- Reconcile. Match each client order ID and exchange order ID, resolve unknown states, account for fees and partial fills, and identify every mismatch.
- Choose the market action deliberately. Cancel, replace, hold, or reduce exposure only under the documented policy and current liquidity conditions.
- Repair and test. Fix the root cause, replay the failed path in a safe environment, verify alert delivery, and complete a clean reconciliation cycle.
- Restart in stages. Begin with observation or shadow mode, then deliberately limited live size. Require a named approver and objective evidence before normal operation resumes.
Documented Monitoring Features Across Bot Platforms
This is a documentation map, not a reliability ranking. Features, plans, interfaces, and supported exchanges can change. Confirm current official documentation and test the exact workflow you intend to use. A platform feature supports crypto trading bot monitoring only when its alerts, logs, and state match your account reality.
| Platform | Documented monitoring capability | What to verify yourself |
|---|---|---|
| Freqtrade | Official docs describe Telegram alerts/control, a monitoring UI, log files, a REST API, and WebSocket RPC messages. | API exposure, authentication, log retention, alert delivery, and exchange reconciliation for your deployment |
| Hummingbot | The Dashboard Instances page exposes active instances and general logs; headless mode uses MQTT for control and monitoring while writing logs to files. | Broker security, remote access, instance ownership, reconnect behavior, and account-state checks |
| Cryptohopper | Baseconfig includes notifications for trades, trade errors, and canceled orders; Advanced View includes the bot output log with errors and decision messages. | Which events notify, channel delivery, configuration overrides, and whether venue-side records reconcile |
| 3Commas | Official Signal Bot help covers performance, bot status, alerts, signal history, and logs. | Exchange connection health, rejected signals, execution state, plan limits, and account-side confirmation |
Cryptohopper documents trade, trade-error, and canceled-order notifications plus an output log for errors and decision messages. Verify the exact events, delivery channel, and exchange-side state before relying on them.
Managed interfaces can simplify crypto trading bot monitoring, but the operator still needs an independent way to confirm critical orders, fills, balances, and positions at the exchange.
If you are choosing an automation platform, compare our best crypto trading bots, best crypto grid trading bots, Cryptohopper review, Bitsgap review, and Bitsgap vs Cryptohopper. Platform selection does not replace an independent monitoring plan.
Daily, Weekly, and Change-Driven Monitoring Routine
Automation should surface urgent problems itself, but a human crypto trading bot monitoring review still catches slow drift and invalid assumptions. Scale the cadence to the strategy horizon, capital at risk, and operational coverage. The schedule below is a starting structure—not a claim that every bot is safe between reviews.
| Cadence | Review | Output |
|---|---|---|
| Continuous | Heartbeat, data age, session health, unknown orders, position mismatch, critical alert delivery | Automated containment and actionable notification |
| Start of staffed window | Open incidents, account reconciliation, version/config, overnight orders and fills | Signed health check or escalation |
| Daily | Error/reject rates, latency tails, partial fills, slippage, fees, abnormal activity | Trend note and threshold review if needed |
| Weekly | Alert usefulness, false positives, missed conditions, capacity/rate budget, log completeness | Monitoring backlog and runbook updates |
| After every change | Deployment marker, first cycles, order path, alert test, reconciliation | Go/no-go evidence for continued operation |
| After every incident | Timeline, root cause, containment, recovery, detection gap | Corrective action with owner and due date |
Use crypto bot paper trading to test normal alerts, stale feeds, rejected orders, and restarts without live capital. Use crypto grid bot backtesting for historical logic, while recognizing that a backtest cannot prove production alert delivery, exchange session health, or state reconciliation.
Record each crypto trading bot monitoring review as a dated operational artifact rather than relying on memory or a transient dashboard view.
Crypto Trading Bot Monitoring Implementation Checklist
Before a live launch, each item needs evidence, an owner, and a last-tested date. “Configured” is not the same as “verified.” A complete crypto trading bot monitoring sign-off proves that detection, containment, investigation, and recovery work as one system.
- Every process emits a heartbeat containing instance, environment, version, and last successful cycle.
- Market and account feeds expose event time, receive time, sequence continuity, and subscription state.
- Exchange time synchronization, reconnect behavior, session renewal, and rate-limit backoff are tested.
- Every decision and order has a correlation ID; retries are idempotent within venue rules.
- Unknown submission status triggers a query or user-stream check before any retry.
- Rejects, partial fills, cancellations, latency, slippage, spreads, and fees have denominators and baselines.
- Open orders, positions, balances, and fees reconcile to authenticated exchange records.
- Material mismatches freeze new risk in the affected scope and open an incident.
- Alerts have severity, persistence, owner, actionable context, secondary delivery, and acknowledgement.
- Logs use a stable schema, UTC timestamps, configuration hashes, and secret redaction.
- Dashboards separate system health, execution quality, state correctness, and strategy performance.
- Every incident has containment rules, evidence preservation, an exchange-side check, and a recovery gate.
- Deployment and configuration changes create timeline markers and trigger first-cycle verification.
- Paper, shadow, and deliberately limited live tests cover disconnects, stale data, timeouts, partial fills, and failed alerts.
Store the completed crypto trading bot monitoring checklist with the deployment record so later incidents can show which controls were tested, by whom, and against which version.
Bitsgap offers managed crypto grid automation. Before live use, verify the exact order states, notifications, exchange records, stop behavior, fee assumptions, and recovery workflow available in your account.
Crypto Trading Bot Monitoring FAQ
What is crypto trading bot monitoring?
Crypto trading bot monitoring is the continuous collection, comparison, and alerting process used to verify that a bot has fresh data, healthy exchange connectivity, correct order states, reconciled balances and positions, and a working human response path.
Which metric should I monitor first?
Start with state correctness: unknown orders, orphan orders, and position mismatches can represent uncontrolled exposure. Then add process heartbeat, data freshness, authenticated session health, errors, latency, fills, execution cost, and alert delivery.
How often should I check a crypto trading bot?
Critical failures should be detected continuously. Human review cadence depends on strategy speed, capital, and coverage. Review account reconciliation and open incidents at the start of a staffed window, execution drift daily, and alert quality and capacity at least weekly.
Is a green “bot running” status enough?
No. The process may be alive while its data is stale, private stream is disconnected, worker is stuck, orders are unknown, or exchange positions differ from local records. Liveness is one signal, not proof of correct operation.
What is an orphan order?
An orphan order is an exchange order the bot does not track, or a local order record that cannot be confirmed at the exchange. Freeze new risk in the affected scope and reconcile client IDs, exchange IDs, fills, cancellations, positions, and balances.
Should a bot retry after an API timeout?
Not blindly. A timeout can leave execution status unknown. Check the authenticated user stream or query the order by its client or exchange ID. Retrying without reconciliation can create a duplicate order.
What should a critical bot alert contain?
Include severity, bot and environment, venue and symbol, first observed time, current state, likely impact, immediate containment, correlation IDs, dashboard or evidence links, runbook, and acknowledgement owner. Never include secrets.
Can monitoring prevent trading losses?
No. Monitoring can reduce detection time and support a controlled response, but it cannot remove market, liquidity, model, exchange, connectivity, security, or execution risk. Orders may fill at unexpected prices or remain unavailable during an outage.
Final Verdict: Monitor State, Not Just Performance
The strongest crypto trading bot monitoring system can answer three questions with evidence: Is the bot receiving valid inputs? Did the venue execute what the bot intended? Does the exchange-confirmed account state match the bot’s ledger? Everything else—dashboards, charts, chat alerts, and uptime badges—supports those answers.
Start with heartbeat, freshness, unknown-order handling, and position reconciliation. Add structured logs, latency and execution distributions, actionable alert severity, and a tested incident runbook. Keep performance analytics separate from operational truth, and never restart simply because the process can run again. Restart when the full crypto trading bot monitoring recovery gate proves that state is understood and controls are working.
Treat crypto trading bot monitoring as permanent production infrastructure: version it, test it, review it after incidents, and improve it whenever a failure exposes a detection gap.
Primary and official sources
- Binance Developer Documentation — General Spot REST API Information (unknown execution status, return codes, rate limits, and backoff).
- Binance Developer Documentation — User Data Stream (authenticated subscriptions and account events).
- Freqtrade — Strategy Quickstart and REST API (Telegram, monitoring UI, logs, API, and WebSocket messages).
- Hummingbot — Managing Instances and Start Strategies and Scripts (dashboard logs and MQTT-based headless monitoring).
- Cryptohopper — General Baseconfig Settings and Advanced View (notifications and output logs).
- 3Commas — Signal Bot Performance and Alerts (status, performance, alerts, and logs).
- Coinrule — Comparing Live Trading and Demo Exchange (demo-environment limitations and validation workflow).
- Google SRE — Monitoring Distributed Systems (monitoring definitions and four golden signals).
- OpenTelemetry — Logs (structured log records and correlation).
- Prometheus — Alerting Practices (simple, symptom-based, actionable alert design).