> For the complete documentation index, see [llms.txt](https://docs.kosmoslabs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kosmoslabs.ai/product-documentation/readme.md). # Getting Started What to expect after connecting your systems *** Welcome to Kosmos. This guide walks you through what to expect after connecting your systems. ### How Kosmos Works Kosmos connects to your existing tools to analyze patterns across your delivery and support data. We identify correlations that identify and prevent recurring incidents before they impact your customers. **Supported integrations:** * **Project Management:** Jira, Linear, Azure DevOps * **Source Control:** GitHub, GitLab, Bitbucket, Azure DevOps * **Setup guides:** [GitHub](/product-documentation/connecting-github.md) · [GitLab](/product-documentation/connecting-gitlab.md) · [Azure DevOps](/product-documentation/connecting-azure-devops.md) · [Salesforce](/product-documentation/connecting-salesforce.md) · [OpenTelemetry](/product-documentation/connecting-opentelemetry-preview.md) * **Support & ITSM:** Salesforce Service Cloud, ServiceNow, Zendesk, Pylon * **Observability:** OpenTelemetry (Preview) * **Notifications:** Slack, Microsoft Teams **Our methodology:** INGEST → CORRELATE → SURFACE → ACT → LEARN ### What Happens After You Connect #### 1. Initial Sync Once your integrations are connected, Kosmos begins syncing data from your systems. This typically takes 10-30 minutes depending on data volume. #### 2. Historical Baseline Your Kosmos team triggers a 90-day historical analysis of your data to create a baseline. This baseline surfaces patterns your team may have been missing—recurring issues, deployment correlations, and systemic risks. #### 3. Results Presentation Within the first week, your Kosmos team will walk you through the findings, including: * Identified Risk Events and their root causes * Correlations between deployments and incidents * Recommendations for prevention Not every correlation Kosmos finds becomes a Risk Event. Your team will walk you through how that line is drawn, and where to find the correlations that did not cross it. See [How a correlation becomes a Risk Event](/product-documentation/understanding-results.md#how-a-correlation-becomes-a-risk-event). #### 4. Ongoing Monitoring After the initial analysis, Kosmos continuously monitors your connected systems to detect emerging risks and alert you before issues escalate. When a Risk Event is detected, you'll receive a notification in your configured Slack or Teams channel. ### Your Dashboard After logging in at [app.kosmoslabs.ai](https://app.kosmoslabs.ai/), the home page is organized as an inbox-first view. Kosmos works on phones and tablets as well as desktop, so you can triage from wherever you are: * **Risk Events inbox** — A hero card at the top shows how many Risk Events are waiting for review, with a breakdown by confidence level and how long the oldest one has been open. Click anywhere on the card to go directly to your Risk Events queue. * **Recent activity** — A feed of the latest team actions on Risk Events: who promoted, dismissed, or acknowledged what, and when. AI-surfaced events are highlighted. * **Background activity** — A summary card showing system stats: signals ingested in the last 24 hours, active clusters, connected systems, and when the engine last recomputed. This is informational — the engine manages this automatically. The left navigation gives you access to: * **Risk Events** — Your action queue. Review, promote to RCA, or dismiss. * **RCA Reports** — Confirmed root cause analyses with correlated evidence * **Correlation Library** — The research view of all clusters the engine has surfaced, including the ones that did not become Risk Events and the reason why. Use for context and investigation, not as a starting point for action. * **Integrations** — Status of your connected systems * **Settings** — Field mappings, notification preferences, and configuration * **Settings → Developer** — API keys and webhook endpoints for programmatic access. See [Managing API Keys and Webhooks](/product-documentation/managing-api-keys-and-webhooks.md). ### Notifications Kosmos sends alerts to Slack or Teams when: * A new Risk Event is detected * An RCA is confirmed Kosmos also sends a Slack alert (not yet available for Teams) if a connected integration disconnects or needs re-authentication, and a follow-up alert once it reconnects—so you can act before it affects your results. Configure your notification channel in Settings → Integrations. ### Getting Help During your trial, your dedicated Kosmos team is your first point of contact. Reach out anytime: * **Email:** * **Your Kosmos contact:** \[Provided during onboarding] ### Linking Doc Pages to Kosmos App Screens (Contextual Deep-Linking) The Kosmos app embeds this documentation site directly in-app. When someone opens the docs while looking at a specific screen (e.g. Observability, Risk Events), the app tries to jump straight to the most relevant page here — instead of always landing on the homepage. This works entirely through **tags you add to pages in the GitBook UI**. There is no code change or deploy involved on the app side — tag a page, wait for the next sync (or trigger one immediately, see below), and it's live. #### How it works, in one sentence A page tagged `page_` becomes the deep-link target for that route in the app; a backend job reads all tagged pages from GitBook once an hour (or on-demand) and keeps the app's mapping in sync automatically. #### Tag format | Tag | App route it links to | Type | | ------------------------------------ | --------------------------------- | ------- | | `page_observability` | `/observability` | Exact | | `page_risk-events` | `/risk-events` | Exact | | `page_settings--developer--api-keys` | `/settings/developer/api-keys` | Exact | | `page_risk-events--dynamic` | `/risk-events/` | Pattern | | `page_risk-events--dynamic--history` | `/risk-events//history` | Pattern | Rules for building a tag: 1. **Always start with `page_`.** Anything not starting with this prefix is ignored — you can use other tags on your pages for your own organization without worrying about conflicts. 2. **Write the app route after the prefix, dropping the leading `/`.** `/observability` → `page_observability`. 3. **Replace each `/` in the route with a double hyphen `--`.** `/settings/developer/api-keys` → `page_settings--developer--api-keys`. 4. **A single hyphen inside one route segment is kept as-is** — it does *not* act as a separator. Only a *double* hyphen (`--`) splits segments. `/risk-events` (one segment, with a hyphen in its name) → `page_risk-events`, **not** `page_risk--events`. 5. **Lowercase, matching the app's URL exactly.** If you're not sure what the exact route is, ask engineering or check the app's URL bar while on that screen. #### Exact tags vs. `dynamic` wildcard segments Most screens are simple: one tag, one page, exact match — use the rules above as-is. Some app screens are **detail pages for a specific record** (a risk event, a correlation, etc.), where the URL includes an ID you obviously can't tag individually (`/risk-events/2374298347`, `/risk-events/8891203744`, …). For these, use the reserved word `dynamic` as a segment wherever the ID would be: ``` page_risk-events--dynamic ``` `dynamic` is a **wildcard that matches exactly one path segment** at that position — it can go anywhere in the tag (start, middle, end), not only at the end. This means you can tag *deeper* pages too, distinct from the plain details page: ``` page_risk-events--dynamic--history ``` This one matches `/risk-events//history` specifically — it will **not** also apply to the plain `/risk-events/` details page, and vice versa. Each depth gets its own tag and its own page: | Tag | Meaning | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | `page_risk-events` | Doc page for the **Risk Events list** screen exactly (`/risk-events`) | | `page_risk-events--dynamic` | Doc page for **a risk event's details** screen (`/risk-events/`, exactly one segment after `risk-events`) | | `page_risk-events--dynamic--history` | Doc page for **a risk event's history sub-screen** (`/risk-events//history`) | Important: a `dynamic` segment matches **exactly one** segment, not "everything below this point." If you need both `/risk-events/` and `/risk-events//history` to have their own docs, tag both — one tag does not automatically cover the other. You only need whichever of these you actually have a doc page for. If only the plain details page exists, only add that one tag. #### One page, multiple app screens A single doc page can carry **more than one `page_*` tag** if it's genuinely the best doc for several app screens at once. Every tag on that page becomes a separate mapping pointing at it. For example, if `Understanding Results` covers signals, deployments, and the correlation library all in one page, tag it with all three: ``` page_signals page_deployments page_correlations ``` The app will deep-link to that same page from any of those three screens. #### Step-by-step: adding a tag to a page 1. Open the page you want to tag in the GitBook editor. 2. Open the page's tag/label panel (in GitBook's page settings — look for **Tags**). 3. Add a new tag using the format above (e.g. `page_observability`). * If the tag doesn't exist yet, GitBook lets you create it inline — just type it. * Re-use the *exact same tag* if it should also apply here (don't create near-duplicate tags like `page_observability` and `page-observability` — they will not both work, only the exact `page_` (underscore) prefix is recognized). * If you don't want to have visible tag on the top of the page, you can hide it with `Tags -> Tag options -> Show tags on page` toggle option. 4. Save/publish the page as usual. 5. That's it — no code change, no deploy, no ticket needed. The app picks it up on the next sync (see below). #### When does the app actually see the new tag? The app doesn't read GitBook live on every click — it syncs on a schedule: * **Automatically, once per hour**, in the background. * **Immediately, on demand** — if you're testing a change and don't want to wait, a Kosmos admin can open the app, go to the docs panel, click the ⓘ **info** icon next to the fullscreen button, and click **Sync now** in the dialog that opens. This pulls straight from GitBook's API and updates the app's mapping within a few seconds. #### How to verify your tag is working The same admin dialog above (ⓘ icon in the app's docs panel — Kosmos admins only) shows a live table of every current tag → app screen → doc page relationship, plus when it was last synced. After tagging a page and syncing, check that table for a row matching your new tag. If it's not there: * Double-check the tag starts with `page_` exactly (not `Page_`, not `page-`). * Double-check there's no typo in the route segment (it must match the app's actual URL). * Confirm the page was actually **published**, not just saved as a draft. #### Common mistakes | Mistake | What happens | | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Typo in the prefix (`Page_observability`, `pages_observability`) | Tag is silently ignored — no error, no crash, it just won't match anything | | Using a single `-` where a `/` should be | Wrong route gets tagged, or (more often) the tag maps to a route that doesn't exist in the app, so nothing links to it | | Tagging the *same* route tag on two different pages | Only one of them will end up as the mapping — don't reuse a `page_*` tag across multiple pages | | Expecting `dynamic` to cover every depth below it | It only matches **one** segment — `page_risk-events--dynamic` covers `/risk-events/`, not `/risk-events//history`; tag that separately | | A tag made of nothing but `dynamic` segments (e.g. `page_dynamic`) | Rejected — there's no literal route left to anchor it to, so it's ignored entirely | #### Quick reference ``` page_ → / (exact) page_-- → // (exact) page_--dynamic → // (pattern, one wildcard segment) page_--dynamic-- → /// (pattern, wildcard in the middle) page_dynamic-- → // (pattern, wildcard first) ``` ### Next Steps 1. Review your connected integrations in Settings 2. Await your Historical Baseline results (your team will schedule the review) 3. Explore initial Risk Events as they appear in your dashboard *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc.