Docs > Platform Observability > Getting Started with Insights
Getting Started with Insights
Overview
This guide introduces AppStatus Insights and covers:
- Blind spots: services reporting nothing at all
- Services sending errors but no other telemetry
- Telemetry with no alert rule attached
- Named user journeys with end-to-end health
- SLO targets and current attainment
What are Insights in AppStatus?
Insights answers the questions your dashboards cannot, because dashboards can only show what you are already collecting. It reports what you are not watching: services that report nothing, services that send only errors, and telemetry that no alert rule is attached to.
It also tracks the flows that matter commercially. A named user journey spans several services, and its health names the worst hop — so you start at the problem rather than reading every service in the path.
Key capabilities:
- Blind-spot detection across silent and partially-instrumented services
- Service ownership: team, on-call channel, runbook, repository and tier
- Named multi-service user journeys with end-to-end health
- SLO targets with current attainment
- Worst-hop naming so triage starts in the right place
What you will see
What the blind-spot report looks like
Scroll the table sideways to see every column.
A silent service is not a healthy service; it is an unmonitored one.
Troubleshooting
A service is flagged silent but is definitely running
It is running without instrumentation, which is exactly the finding. Add an SDK or agent, or record it as deliberately out of scope so it stops appearing in the report.
Journey health looks worse than every individual service
That is expected and useful. A journey spans several hops, so small delays compound. Read the worst-hop name rather than comparing service dashboards one by one.
The SLO is always met but users still complain
The target is probably measuring the wrong thing — availability when users feel latency, or a service-level metric when the journey is what they experience. Move the SLO onto the journey.
Operational Guidance
- A silent service is not a healthy service; it is an unmonitored one.
- Journey health names the worst hop, so start there instead of reading every service.
- Telemetry with no alert rule attached is data nobody will see at 3am.
Step-by-Step Setup
Insights is the page you set up once and then re-check whenever a new service ships. Most of the setup is recording things you already know but have never written down — who owns what, and which flows actually matter.
Before you start
- At least one service already reporting telemetry
- 1
Read the blind-spot report first
Open the blind-spot list before configuring anything. It shows services reporting nothing, services sending only errors, and telemetry with no alert rule attached — usually a more useful first hour than any dashboard.
WhereInsights → Blind spots - 2
Record service ownership
For each service, record the owning team, on-call channel, runbook link, repository and tier. Ownership drives alert routing, so a name without a channel is only half the answer.
WhereInsights → Service ownershipTipThe runbook link is the field people skip and the one that matters most at 3am.
- 3
Define the journeys that matter
Name the multi-service flows that make money — signup, checkout, search. A journey spans several hops and its health names the worst one, so triage starts at the problem instead of a list of services.
WhereInsights → Journeys - 4
Set SLO targets
Set targets on the journeys you named. Pick something you would actually defend in a review — 100% is not a target, it is an aspiration that guarantees you miss it.
WhereInsights → SLOs - 5
Close the gaps and re-check
Work through the blind-spot findings, then come back after each new service ships. The report is only useful if it stays current.
WhereInsights → Blind spots
Configuration Options
Every option you can set, what each choice means, and what to pick. Use this as a reference while you fill in the form.
Ownership and targets
| Field | Options | What it does | Recommended |
|---|---|---|---|
| Service owner | Team + channel | Who is accountable and where to reach them. | Include an on-call channel and a runbook, not just a name. |
| Tier | Critical / standard / low | How critical the service is. | Drives alert routing — keep it honest. |
| Journey | Named flow | A multi-service user path. | Model the flows that make money first. |
| SLO target | Percentage | The reliability you commit to. | Something you would defend. Never 100%. |
Feature Reference
Every feature, where to find it in the app, and what it does. Use this when you know what you want to do but not where it lives.
| Feature | Where in app | Description |
|---|---|---|
| Blind spots | Insights → Blind spots | Silent services, error-only services, and telemetry with no alert rule. |
| Service ownership | Insights → Ownership | Team, on-call channel, runbook, repository and tier. |
| Journey health | Insights → Journeys | End-to-end health with the worst hop named. |
| SLO tracking | Insights → SLOs | Targets and current attainment. |
Next Steps
Continue building your monitoring stack:
