Observability or process SLA monitoring: systems vs business cases

What observability covers

Observability platforms collect metrics, logs and traces from your applications and infrastructure and alert when something looks wrong. In Datadog, a monitor can also notify when a metric stops reporting: the option to show NO DATA and notify fires when expected data is missing, provided the monitor has evaluated data before.

Incident tools such as PagerDuty sit on top. Events from monitoring tools become alerts, alerts become incidents, and incidents are routed and escalated to whoever is on call, with notifications by phone, SMS, email and push.

Some observability vendors go further into business processes. Dynatrace Business Flow monitors process flows from business events that share a correlation ID such as order_id, and shows delays, dropped and incomplete flows and business KPIs. Its documentation also lists limits: at most five branches per step, five business events per step and 20 nodes per process, and alerting on key metrics only when a process takes on average less than 30 minutes, because anomaly detection uses a 60-minute rolling window.

What process SLA monitoring covers

Process SLA monitoring treats each order, ticket or refund as a case with steps and deadlines. tiqline links events to a case by an ID, such as the order number, and checks each step against its time limit. A step can be minutes, hours or days long; the deadline is the time the case reached the step plus the limit.

When the deadline passes without the next event, the case is marked as stuck. All stuck cases of one step share one incident, and one alert goes to Slack or email with the process, the step, the time limit and a link to the cases.

The key differences

• Object: observability watches services and hosts. Process monitoring watches cases such as orders.
• Signal: observability reacts to errors, latency and missing data. Process monitoring reacts to a business step that did not happen in time.
• Time scale: system alerts are usually about seconds and minutes. Business steps often take hours or days, such as a refund within two days.
• Who acts: system alerts go to engineers on call. Process alerts go to operations, customer service or the warehouse.
• Setup: observability needs agents or instrumentation. tiqline needs events per step and a process description.

Side by side

When observability is enough

If every late order traces back to a failing system, observability already catches it. A webhook endpoint that returns errors or a queue that stops draining shows up in your metrics. A Datadog monitor that notifies on missing data can also catch the moment orders stop flowing altogether.

When you need process SLA monitoring

You need it when the systems are fine but the work is not. A warehouse that is short of staff, a payment that waits for manual review, a refund nobody approved: no error is thrown, no metric spikes. The only signal is that an event did not arrive in time for one specific order. That is the gap tiqline fills.

Using both together

Keep your observability stack for system health and add tiqline for the business steps. Send events from your services through the track API at the points where a business step completes, and include your trace_id. When an order is stuck, the case timeline in tiqline shows each event with its trace_id, so an engineer can jump to the matching trace if the cause turns out to be technical.

Route the two kinds of alerts to different people. System incidents go to the on-call engineer. Process alerts from tiqline go to the Slack channel or email addresses of the team that can move the order.

Example: all green, still late

All numbers in this example are made up for illustration. A shop processes 500 orders a day. Its APM dashboards are green all Monday. In the afternoon, a carrier pickup is missed and the warehouse stops marking orders as picked.

In tiqline the pick step has a time limit of 5 hours. At 4:10 p.m. 37 orders are past that limit. One Slack message names the step and says 37 cases are waiting, and the email lists the cases. The warehouse lead calls the carrier. No system alert fired, because no system failed.

Setting it up in tiqline

• Send an event through the track API at each point where a business step completes, and include the trace_id if you have one.
• Choose the ID field that links events to a case, for example the order number.
• Describe the steps in the process editor and set a time limit for each step after the first. Add a branch where cases split, for example shipped or cancelled.
• Preview the draft on your real cases before you publish it, so you see which cases would be stuck today.
• Choose the alert channels: a Slack channel through an incoming webhook, up to 20 email addresses, or both.
• Publish. A time limit you change later applies at once, also to cases that are already running, and the change is recorded in the audit log.

Limits of tiqline

tiqline is not an observability tool. It does not collect metrics, logs or traces, does not monitor uptime and does not detect anomalies. It has no on-call schedules, no escalation policies and no phone or SMS alerts; alerts go to Slack and email. It only knows what it receives as events, so a step that sends nothing cannot be watched.