Reliability is not a “nice to have” technical attribute. It is a commercial capability. In enterprise and mid-market software, buyers assume the product will be available, predictable, and safe; when it is not, the consequences show up quickly as churn risk, expansion friction, discounting, escalations, and a rising cost-to-serve. Even in SMB-focused products, reliability failures create hidden drag by driving support tickets and consuming engineering capacity that should be shipping roadmap value.
10.1 SLOs/SLAs and Historical Uptime: What to Request and How to Interpret
Start by separating three terms that are often used interchangeably but mean different things. SLOs: internal reliability targets the team uses to operate the service. SLIs: the measurements behind those targets (latency, error rate, availability, freshness). SLAs: external contractual commitments made to customers, often with service credits. A company can have an SLA without meaningful SLOs, and that is usually a warning sign: commitments are being sold without an operational control system to meet them predictably.
In diligence, you want to see the “truth sources” the company uses to understand reliability. Do not accept a single percentage on a slide. Ask for artifacts that show what was measured, over what window, and with what exclusions. A minimum viable evidence set usually includes: recent SLA language from contracts, any documented SLOs or internal targets, 12 months of availability reporting, and a list of material incidents with impact summaries.
Requesting the right uptime view matters because “99.9%” can hide very different realities. Ask for availability by month and for the measurement definition. Definition: does severe degradation count, or only total outage? Scope: is availability measured for the whole system, for critical APIs, or for the core workflow? Population: is it averaged across tenants, or segmented by tier, region, or top customers? Customers experience their own availability, not the platform average.
Interpret uptime through the lens of customer impact and segment expectations. Also examine time concentration. A single brief outage can be less damaging than repeated smaller degradations during peak business periods. Ask for the top incidents by customer impact and whether they correlate with renewal pressure, discounts, or escalation volume.
Push beyond availability into performance commitments. Many “uptime” issues are actually latency issues. If the product responds but is too slow to be usable, customers describe it as down. Ask for p95 or p99 latency for core endpoints or workflows, error rates, and any known peak-period degradation. If the company has no performance targets, ask what they watch during rollouts and incidents; the answer reveals what they consider “service health.”
When SLAs exist, examine how they are structured. Coverage: are SLAs uniform, or tiered by plan? Exclusions: do they exclude planned maintenance, third-party failures, or customer misconfiguration? Measurement: does the company measure independently, or does the customer measure? Frequent disputes or credits are signals of either reliability problems or ambiguous definitions, both of which increase renewal friction.
A practical interpretation technique is to translate availability into an intuitive “downtime budget” and compare it to the target segment bar. For example, 99.9% monthly availability implies roughly 43 minutes of downtime per month, while 99.99% implies roughly 4 minutes. The exact number is less important than the implication: if the company targets enterprise but regularly exceeds its implied downtime budget, the gap must be priced and planned.
Reconcile reported availability with how customers experience the product. “Up” can still feel “down” when a critical dependency—search, reporting, background jobs, or an integration endpoint—is degraded. Ask support or CS for recent availability escalations and trace what monitoring showed at the time; this surfaces partial-failure blind spots that pure uptime percentages miss.
If the target cannot provide a clean 12-month uptime series, pivot to incident-driven evidence: incident log with duration and impact, status page history, and customer communications. You may not get a precise percentage, but you can still underwrite frequency, peak-period concentration, and response discipline.
Finally, assess whether reliability is managed proactively. Strong signals include: targets tied to user-visible outcomes, dashboards watched routinely, and a reliability review cadence that produces concrete actions. Weak signals include: reliance on customer complaints for detection and an absence of clear targets. The goal is not to punish immaturity; it is to quantify the gap and determine whether closing it is feasible within the first year of ownership.
Use this request checklist to keep the evidence set tight:
- SLA artifacts: standard SLA language plus any bespoke SLAs for top customers.
- Availability reporting: 12 months of monthly availability for core service(s), with definitions.
- Performance reporting: latency and error rate trends for critical workflows or APIs.
- Incident summary: list of sev-1/sev-2 incidents with duration, impact, and root cause category.
Those artifacts, interpreted with definitions and segmentation, are enough to convert “reliability” from a vague concern into an under-writable view.
10.2 Incident Management: Postmortems, Recurrence, and Cultural Maturity
Incidents are inevitable in software at scale. What differentiates strong operators from weak ones is not whether incidents happen; it is how the organization responds, learns, and reduces recurrence. Incident management is therefore one of the highest-signal diligence areas because it reveals both near-term customer risk and the company’s ability to improve reliability over time.
Begin by asking for the incident lifecycle. Detection: how an incident is identified. Triage: how severity is assigned and who is paged. Mitigation: how service is restored and customer impact is contained. Communication: how customers and internal stakeholders are updated. Learning: how root causes are identified and prevention work is tracked to completion. A mature lifecycle can be lightweight; it just needs to be consistent and practiced.
Ask for a sample set of incidents rather than only a summary. Three to five recent high-severity incidents are usually enough, plus one “near miss” that was caught before major impact. For each, review the timeline and the postmortem or write-up. The best postmortems include: a clear narrative, customer impact, contributing factors (not just the proximate cause), and action items with owners and due dates.
Recurrence: Recurrence is the critical underwriting signal. One-off incidents happen even in strong organizations. Repeat incidents indicate systemic weakness: brittle dependencies, poor change controls, inadequate capacity management, or lack of follow-through on prevention. Ask explicitly which failure classes dominate and whether repeat rates are improving. Common repeat classes include database contention, bad deployments, vendor dependency failures, integration storms, and data pipeline issues.
Also evaluate how severity is defined and whether definitions are used consistently. A practical severity system ties to customer impact and expected response. For example, a top-severity incident might mean “core workflow unavailable for a meaningful portion of customers,” while a lower-severity incident might mean “degraded performance with workarounds.” What matters is that the organization can make fast, consistent choices about who gets paged, what level of escalation is required, and what customer communication is warranted. Inconsistent severity labeling usually correlates with inconsistent response and unclear accountability.
When you review incident response, look for role clarity. Mature teams assign an Incident commander: coordinates, keeps time, and manages communication; a Technical lead: drives investigation and mitigation; and a Communications owner: updates support, CS, and customers. The same person can wear multiple hats in smaller companies, but the functions should exist. If the technical lead is also trying to manage customer comms and coordinate a bridge, MTTR tends to increase and customer experience suffers.
If you are working under limited access, use a simple triangulation tactic: ask engineering for their top three incident pain points, ask support for their top three customer-impacting reliability pain points, and ask the exec team for their top three “trust risks” raised by customers. Where these lists overlap, you have the likely highest-ROI reliability initiatives. Where they diverge sharply, either measurement is weak or cross-functional communication is broken—both of which increase risk.
Use simple operational metrics where available. MTTD: mean time to detect. MTTR: mean time to restore. Change failure rate: how often deployments cause incidents or require hotfixes. Repeat rate: how often the same failure mode reappears. If the company does not track these, use directional evidence: paging volume, incident counts by severity, and whether leaders can show a trend over time.
Cultural maturity: Culture predicts whether reliability will improve. The most useful standard is “blamelessness with accountability.” Blameless means the team focuses on system factors rather than individual fault. Accountability means action items are owned, tracked, and completed. If action items stay open for months, the organization is accumulating reliability debt even if the incident write-ups look polished.
Also examine the support interface. When incidents occur, do support teams have clear guidance and timely updates? Are customer-impacting issues logged centrally, or do they fragment across chats, tickets, and emails? Fragmentation increases customer frustration and raises the cost of response.
Translate incident evidence into underwriting conclusions. Current risk: likelihood of a major customer-impacting incident in the next 12 months, based on frequency and recurrence. Trajectory: whether repeat rates and MTTR are improving or stagnating. Investment needs: whether the company needs stronger release controls, vendor resilience, capacity planning, or reliability engineering bandwidth. These conclusions should feed the risk register and the first-year value-protecting plan.
Use this lightweight postmortem outline as a diligence lens, even if the company does not use it formally:
- What happened: timeline from detection to resolution.
- Customer impact: which workflows were affected, how many customers, and for how long.
- Root causes: proximate cause plus contributing factors (process, tooling, architecture).
- Prevention actions: specific changes with owners and due dates.
- Verification: how the team will confirm the issue cannot recur in the same way.
If the artifacts align to this outline and prevention work closes reliably, incident management is likely mature enough to support scaling. If not, you have found an operational risk that must be priced and planned.
10.3 Observability: Monitoring, Logging, Tracing, and Alert Hygiene
Observability is the operating system of reliability. Without it, incidents are detected late, root causes remain ambiguous, and teams compensate through heroics and tribal knowledge. With it, teams can manage growth confidently because they can see what is happening, where it is happening, and why it is happening.
In diligence, avoid getting lost in tooling. A company can have sophisticated tools and still be blind if instrumentation is inconsistent or alerts are noisy. A simpler toolset can be sufficient if it is aligned to user-visible outcomes and used consistently. The right question is: can the team detect and diagnose issues fast enough to protect the core workflows that drive retention?
Start with a “three-layer” view. Monitoring: metrics and dashboards that show service health. Logging: event records that support debugging and auditing. Tracing: visibility into distributed request paths where multiple services interact. Not every company needs deep tracing, but most companies with multiple services and integrations benefit from it as complexity grows.
Ask to see the dashboards the on-call engineer uses during an incident, not the dashboards made for exec reporting. Look for metrics tied to user experience: request success rate, latency percentiles, queue depth, database health, and critical external dependency health. Ask whether the team can segment by tenant, region, or tier. Without segmentation, large customers create outsized risk because issues are harder to isolate and mitigate.
Logging posture should be assessed through three lenses: Completeness: logs exist for critical workflows and security-relevant events. Usefulness: logs are structured enough to query by tenant, request ID, and error class. Cost discipline: log volume is controlled so observability does not become avoidable margin drag.
One diligence objective is to confirm that observability is embedded in the development process, not bolted on afterward. Ask whether teams use consistent conventions for metrics and logs, whether new services must include baseline dashboards, and whether alerts are reviewed after major changes. If the company is shipping frequently but observability lags, detection will rely on customer complaints and the organization will struggle as scale increases. If observability is part of “definition of done,” reliability improvements tend to compound over time.
Also check whether the company can correlate customer experience changes with deployments. During a walkthrough, ask the operator to pick a recent release and show how they verify it in production: which dashboards are watched, what thresholds would trigger a rollback, and how the release is annotated in monitoring tools. This is a fast test of operational rigor. Teams that can quickly answer “what changed” during an incident typically restore service faster and reduce recurrence because they can isolate causes.
Alert hygiene is a critical maturity signal. In many companies, alerts are either too noisy (burnout) or too quiet (customers detect issues). Ask how alerts are tuned, who owns them, and whether paging is tied to SLO-like signals. If the on-call engineer receives constant pages that are not actionable, the system is not operable at scale.
Run a fast scenario test. Scenario: a large customer reports slowness. How does the team confirm impact, isolate whether it is tenant-specific, and identify the bottleneck? Scenario: an integration starts failing intermittently. How is it detected, and how is vendor versus internal fault determined? Scenario: a deployment increases error rates for a subset of endpoints. How quickly is it noticed and mitigated? The answers reveal whether observability is connected to operational practice.
Weak observability increases downside risk and increases operating cost through longer incidents and higher support burden. The good news is that observability improvements are often high-ROI. In the first 100 days, teams can typically implement a basic workflow SLO dashboard, improve tenant-level tagging, reduce alert noise, and standardize logging for critical paths. These changes do not require rewriting the product; they require discipline and ownership.
Use this quick checklist to summarize observability readiness:
- Workflow health: core workflows have clear success, latency, and error signals.
- Tenant segmentation: teams can diagnose issues by tenant/region/tier.
- Actionable alerts: paging is tied to meaningful thresholds; noise is managed.
- Release monitoring: deployments are correlated with metrics and have clear rollback triggers.
That checklist produces an actionable conclusion: whether observability is a current constraint on reliability and scale, and what upgrades are required to reduce risk.
10.4 Support Economics: Ticket Drivers, Escalations, and Product Gaps
Support is where reliability, product usability, and unit economics converge. A high support burden can be caused by incidents, but it is just as often caused by product gaps: confusing workflows, brittle integrations, poor admin tooling, weak self-serve onboarding, and missing guardrails that allow users to misconfigure the system. From an investor perspective, support burden matters because it drives gross margin, reveals hidden churn mechanisms, and consumes engineering capacity through escalations.
Support diligence should answer three questions. Volume and mix: how many tickets exist and what they are about. Cost and scaling: how support effort scales with ARR and customer count. Root causes: which issues are best solved through staffing and process versus productization and platform work.
Start with a ticket taxonomy. Ask for ticket volume trends for the last 6–12 months and the top categories by volume and by effort. If the company lacks a meaningful taxonomy, that is a finding: it cannot manage support as a system. In that case, ask support leaders to walk through dominant drivers and provide a sample export so you can validate patterns.
Look for a small set of dominant drivers. In many businesses, a minority of categories drive most effort. Common drivers include onboarding/configuration confusion, data imports and quality issues, integration failures, reporting limitations, permission and access issues, and performance complaints. Each driver maps to a different fix. The diligence goal is to identify which fixes are product and platform work, not just staffing.
Escalations: Escalations to engineering are the highest-signal economic indicator. Ask how many tickets escalate, why, and how long resolution takes. Then ask what happens after resolution: is the issue eliminated for the broader base, or does it recur? Frequent recurring escalations create an “engineering support tax” that will grow with the customer base unless product gaps are addressed.
Segment support by account where possible. A few large customers can drive disproportionate support effort because of complex integrations, heavy usage, or bespoke configurations. If the top accounts drive a large share of support time, you have operational concentration risk that should be explicit in the underwriting narrative and managed in the post-close plan.
Do not ignore the support operating model. Tiering, knowledge management, and clear escalation paths can reduce cost-to-serve. However, process alone cannot solve product-driven support. Sustainable improvement comes from productization: building self-serve capabilities, better error messages, validation tools, and admin features that reduce the need for human intervention.
Ask for a few support performance metrics to understand scaling behavior: first response time, time to resolution by severity, reopen rate, and ticket backlog trend. These are early signals of churn risk in segments that expect responsive support.
Then evaluate deflection and the support-to-product loop. Knowledge base and in-product guidance matter, but the biggest levers are productized: clearer errors, validation, and customer-facing health indicators for integrations and data. Ask for one example where product work measurably reduces a ticket category; without this loop, support becomes a permanent tax.
A high-leverage output is a translation from top ticket drivers to a value-creation backlog. Use this practical mapping:
- If tickets are about confusion: improve UX, onboarding, in-product guidance, and defaults.
- If tickets are about integrations: productize connectors, improve API ergonomics, strengthen error handling, and add customer-facing integration health views.
- If tickets are about data quality: add validation, previews, reconciliation tools, and clearer failure messages.
- If tickets are about access: improve role design, admin tooling, and auditability.
- If tickets are about performance: address bottlenecks and improve observability and capacity management.
Close by tying support economics back to underwriting. If support burden is high and rising, margin expansion assumptions should be discounted unless there is a credible productization plan. If escalations are frequent, roadmap timelines should be discounted unless engineering capacity is protected and repeat issues are eliminated. If dominant drivers map cleanly to fixable product gaps, support is not just a cost center; it is a roadmap signal that can unlock both margin and retention improvements.
Treat reliability work as value creation, not just risk reduction: fewer incidents cut support cost, accelerate onboarding, preserve pricing power, and free engineering capacity for growth features over time.
Reliability and operations diligence is ultimately about trust. Customers trust the product when it works, failures are rare and well-handled, and communication is clear. Investors trust the plan when they can see the operational system that will deliver it. The methods in this chapter turn operational reality into that kind of trust.
