Documentation

Visit /register and sign up with your email address. You can also sign in with GitHub if your organization uses it.

On first login you will be prompted to create an organization — this is the shared workspace for your team.

Go to Dashboard → New Environment and give it a name like production or staging. You can add an optional cluster name for Kubernetes setups.

Install the CLI (see CLI Reference) and run:

kollaber login --api https://kollaber.io --email you@example.com
kollaber deploy --env production --service api --version v1.0.0

Head back to the dashboard — your deploy event will appear in the timeline immediately.

Each environment has its own timeline. Events are sorted newest-first and show the event type, service name, timestamp, and any attached metadata (version, author, etc.).

New events and comments are pushed over a live connection as they are recorded — no polling, no refresh needed. A coloured badge indicates the event type:

• DEPLOY — a service release recorded via the CLI, CI, or webhook
• ALERT — an alert ingested via webhook
• NOTE — a manual note added by a team member
• ROLLBACK — a release that reverted a previous one
• SCALE — a replica or resource change
• TEARDOWN — a service or workload removed

The Searchpage runs one query across event text and comment bodies at once — a comment match comes back with the event it was written on, because a quote with no context tells you someone wrote “rolled it back” but not what they rolled back or when. Scope it to a single environment or search the whole org.

Event text indexes metadata values only, never keys — indexing keys would make a search for version match every deploy you have ever shipped.

Matching is on whole stemmed words, so check does not find checkout and rollback does not find rolling back.

On an alert or a failed event, choose Suspect changes. Kollaber returns the changes that preceded it in the same environment, ranked and scored 0–100, each with the reasons that produced its score — same service, how long before, whether the change failed.

The scores are heuristics for ordering, never a causal claim, which is why every response shows its working. Nothing extra is collected to produce them; it is a query over events you already have.

The Metrics page reports the four DORA metrics — deploy frequency, lead time for changes, change failure rate, and time to restore service — over a window you choose, with a trend line for each.

Lead time needs a commit timestamp on deploys: pass --committed-at to kollaber deploy, or a committed_at field in webhook metadata. Time to restore is derived from incidents and is always org-wide; scoping to an environment narrows the other three only.

From the timeline header, pick an environment and a time window and Kollaber returns a markdown document: the event sequence, every comment thread grouped under the event it belongs to, the participants, and an AI narrative summary.

The factual half is assembled from your own rows and is returned on every plan, with or without an Anthropic key configured; only the narrative section needs the Pro entitlement. A narrative_status field says which of those held, so a missing summary reads as an explained gap rather than a failed request.

Comments are selected by their event’s timestamp, not their own — analysis written a week after an outage is exactly the considered thinking a postmortem wants. One document caps at 500 events and 1000 comments, and the narrative works from the most recent 120 events.

A Monday recap of the week that ended: deploys and failures per environment, rollbacks, alerts, incidents opened and resolved, and the events that drew the most discussion. Opt in under Settings → Notifications, alongside the rest of Kollaber’s email.

Threads are ranked by comments written duringthe week rather than by the event’s own age, so a months-old event the team argued about on Tuesday still surfaces. A week with nothing in it sends nothing, and quiet environments are dropped from the email.

Click any event to expand it. Use the comment box to leave context — root cause, rollback decision, follow-up ticket, anything. Comments are timestamped and attributed to the author.

Declare a period when the team would rather nothing changed — Black Friday, quarter end, the week a migration lands — under Settings → Change freezes. Scope it to one environment or leave it org-wide.

Kollaber does not block anything. A deploy that lands inside a freeze is recorded as having done so, the timeline shows it, and kollaber deploy exits 2 so CI can decide whether that fails the build. Pass --allow-frozen for a release that is meant to go out anyway. Blocking would put Kollaber on the critical path of every deploy, which is a promise a tool that sits beside your stack should not make.

kollaber deploy --env prod --service api --version v1.2.3
# WARNING: change freeze in effect — this environment is frozen: Black Friday
# exit status 2

Only changes are flagged — deploys, rollbacks, scales and teardowns. An alert firing or a note being written during a freeze is not a violation of anything. Admins declare and remove windows; removing one does not unmark deploys that already landed inside it, because those recorded what was true when they happened.

The Inventorypage answers “what was in prod when this broke?” — the version of every service in an environment at a moment you choose, derived from deploy history. Nothing extra is collected to produce it.

Only successful deploys and rollbacks count: a failed deploy did not change what is running, and an in-progress one has not landed. A rollback is flagged, because what is running is then not the newest thing anyone shipped.

The version is read from version, then image_tag, revision, head_commit, and to — the keys the CLI, Kubernetes watcher, Argo CD and Atlantis each use. If the deploy that landed carried none of them the service reads version not recorded rather than showing the previous one, which would name a build that is not running.

The environment and the instant both live in the URL, so an inventory is a link you can paste into an incident thread.

Open a comment thread and choose Mark as decisionto promote it. “We’re rolling back” and “accepting this risk until Q3” are the highest-value lines in a timeline and are otherwise indistinguishable from “looking into it”.

The Decisions page lists them newest first, each with the event it was written on — a decision without its subject is not readable six months later. Filter by environment; the filter lives in the URL, so a filtered log is a link you can send someone.

Marking is curation, not an edit: the text stays exactly as written, and Kollaber records who promoted it, which is not necessarily who wrote it. Viewers cannot mark or unmark. Unmarking clears the attribution so a re-marked comment never carries a stale one.

On the Team plan and above, open the assistant from the spark icon in the bottom-right of the timeline. Ask questions in plain language — “what deployed today?”, “summarize the latest alert and its discussion” — and it answers by reading your real events and comments, streaming the reply as it goes. It only reports what it finds in your data and never invents events. You can also query it from the terminal with kollaber ask.

Go to Settings → Members to invite teammates via email. Each member can be assigned one of four roles:

• Owner — full control including billing and org deletion
• Admin — manage members, environments, and all events
• Member — create events and comments
• Viewer — read-only access to the timeline

Go to Settings → Notifications. Check the event types you want to be notified about and optionally enter a notification email address:

• Deployments — emailed when a deploy event is recorded
• Alerts — emailed when an alert event is recorded
• Notes — emailed when a note is added to the timeline
• Weekly digest — a Monday recap of the week that just ended

The Notification email field lets you receive alerts at a different address than your account email — useful for shared inboxes or on-call aliases. Leave it blank to use your account email.

Preferences are saved per organization. Members who have not configured preferences receive no emails by default.

Tick Weekly digest under Settings → Notifications to get a Monday recap of the week that just ended: deploys and failures per environment, rollbacks, alerts, incidents opened and resolved, and the events that drew the most discussion.

Threads are ranked by comments written during that week rather than by the age of the event, so a months-old event the team argued about on Tuesday still surfaces — which is exactly the conversation you would otherwise miss.

A week with no events, no incidents and no discussion sends nothing. Environments that saw no activity are left out of the email rather than listed as rows of zeroes.

Self-hosted: the schedule runs inside the API, so there is no cron to configure. Running more than one replica is safe — each send is claimed in the database, so exactly one pod mails each org. Set DIGEST_SEND_HOUR to move it off 14:00 UTC, or DIGEST_DISABLED=true to turn it off entirely.

When any event is created (via the CLI, webhook, or UI), Kollaber fires all configured channels asynchronously — email recipients, the Slack webhook, and the Teams webhook all receive a notification without blocking the API response.

Go to Settings → Slack and paste an Incoming Webhook URL. To get one:

1. Open your Slack workspace's App Directory and install Incoming Webhooks
2. Choose a channel and click Add Incoming Webhooks integration
3. Copy the generated webhook URL and paste it into Kollaber

Use the Send test message button to verify delivery. Slack messages include the event type (with an emoji), the service name, and the environment.

Go to Settings → Teams and paste an Incoming Webhook URL. To get one:

1. Open the target Teams channel and click ··· → Connectors
2. Search for Incoming Webhook and click Configure
3. Give it a name, click Create, then copy the webhook URL

Teams messages are sent as colour-coded MessageCard payloads — blue for deploys, red for alerts, purple for notes.

Kollaber serves deploys, rollbacks, scales, teardowns and alerts in Grafana's JSON annotation format, so your changes render as vertical lines on the dashboards you already have. Kollaber is the datasource here — Grafana pulls from it on each dashboard refresh, so there is nothing to push and nothing to keep in sync.

Add a JSON datasource in Grafana — Infinity works with the GET form, and simpod-json-datasource with the POST form. Point it at your Kollaber URL and add a request header of Authorization: Bearer <token>, using a CLI token from the top-right menu → Generate CLI token. The token carries the organization, so a dashboard only ever sees that org's events.

# Everything in the last 24 hours
curl -H "Authorization: Bearer $TOKEN" \
  https://kollaber.io/annotations

# One environment, deploys and rollbacks only
curl -H "Authorization: Bearer $TOKEN" \
  "https://kollaber.io/annotations?environment_id=<uuid>&type=deploy,rollback"

Both from and to accept RFC3339 or epoch milliseconds and default to the last 24 hours. Filters are environment_id, service, and type (comma-separated). With the POST form, put those same filters in the annotation query box as a query string, for example type=deploy&service=api.

Each annotation is tagged with its type, environment and service, plus its status when that status is something other than success — so a Grafana panel can filter down to failure alone. Notes are left out by default, since a dashboard marker should record something that happened to the system rather than something someone said about it; ask for type=note if you want them.

Only owners and admins can save or clear the Slack and Teams webhook URLs. Members and viewers can see whether a webhook is configured but cannot change it.

Install with Go:

go install github.com/urbangeeks/kollaber/cmd/kollaber@latest

Or download a pre-built binary from the downloads page.

Defaults to https://kollaber.io (the hosted service). Set theKOLLABER_API environment variable (or --api on login) to point at a self-hosted instance.

Authenticate and save a token to ~/.kollaber/config.json.

# Email — sends a one-time code, then prompts you to enter it
kollaber login --api https://kollaber.io --email you@example.com

# CLI token from Settings → API Tokens (for GitHub OAuth users)
kollaber login --api https://kollaber.io --token <your-token>

List all environments in your organization.

kollaber envs

Record a deploy event.

kollaber deploy \
  --env production \
  --service api \
  --version v1.2.3

Exit codes: 0 recorded, 2 recorded but landed inside a change freeze, 1 anything else. The event is always created — the distinct code is so a pipeline can tell a freeze apart from a network failure.

Drop a manual note into the timeline — useful for maintenance windows or on-call observations.

kollaber note --env production "Rolling back v1.2.3 due to 5xx spike"

View recent events for an environment.

kollaber timeline --env production --limit 20

Group related events into an incident, track its status, and link events together. Useful from CI — open an incident and attach the failing deploy in one step.

kollaber incident list                      # all incidents
kollaber incident list --status open        # filter by status

kollaber incident open --title "5xx spike on api" --severity sev2
kollaber incident open --title "Deploy failed" --severity sev2 --event <event-id>

kollaber incident attach <incident-id> --event <event-id>
kollaber incident resolve <incident-id>                  # defaults to resolved
kollaber incident resolve <incident-id> --status mitigated

Ask the AI timeline assistant a natural-language question about your events. The answer streams to stdout while tool lookups print to stderr, so you can pipe the answer cleanly. Requires the Team plan or higher.

kollaber ask --env production "what deployed in the last hour?"
kollaber ask "summarize today's alerts" > summary.txt

Conversations persist across commands, so follow-ups keep context. Run with no question to open an interactive multi-turn session (type exit to quit).

kollaber ask "what was the last alert?"
kollaber ask "yes, show its metadata"   # remembers the previous turn

kollaber ask --env production           # interactive session

Report the four DORA metrics from the terminal or a CI job.

kollaber dora                             # last 30 days, all environments
kollaber dora --days 7                    # last 7 days
kollaber dora --env production --days 90  # scope to one environment

Lead time needs a commit timestamp on deploys. Time to restore is derived from incidents and is always org-wide — --env narrows the other three metrics only.

Run the Model Context Protocol server over stdio — see MCP Server below.

kollaber mcp

The server reuses the token the CLI already saved, so authenticate once:

kollaber login
claude mcp add kollaber -- kollaber mcp

Any MCP client works:

{ "mcpServers": { "kollaber": { "command": "kollaber", "args": ["mcp"] } } }

Then ask things like “what deployed to production in the last hour?” or “what changed right before this alert fired?”

The six read tools are annotated readOnlyHint, so clients can run them without prompting. add_note and add_comment write to a shared team timeline and are not.

find_related_eventsis the one worth knowing about — anchor it on an alert and it returns the deploys that preceded it, which is the question you actually have at 3am. Events sharing the anchor’s timestamp to the second land in a separate concurrent bucket rather than being reported as causes, since the API serializes timestamps at second precision and cannot order them.

Unlike kollaber ask, which runs inference against the server’s Anthropic key and needs the Team plan, the MCP server runs on your own client’s model — so it works on every plan, self-hosted included.

The watcher runs as a Deployment inside your cluster using a ServiceAccount with read-only access to Deployments, StatefulSets, DaemonSets, and Pods. Install one release per cluster:

helm install kollaber-watcher oci://ghcr.io/urbangeeks/charts/kube-watcher \
  --set kollaber.env=prod \
  --set kollaber.api=https://kollaber.io \
  --set kollaber.token=<cli-token>

Get your CLI token from the dashboard under Settings → CLI Token.

Install a separate Helm release for each cluster, pointing each one at the matching Kollaber environment:

helm install kollaber-watcher-prod    oci://ghcr.io/urbangeeks/charts/kube-watcher --set kollaber.env=prod    ...
helm install kollaber-watcher-staging oci://ghcr.io/urbangeeks/charts/kube-watcher --set kollaber.env=staging ...

Events from each cluster will appear in their respective environment timelines in the dashboard.

If you manage secrets externally (Vault, Sealed Secrets, External Secrets Operator), skip secret creation by pointing at your own:

# Your secret must have a key named "token"
kubectl create secret generic my-kollaber-token --from-literal=token=<cli-token>

helm install kollaber-watcher oci://ghcr.io/urbangeeks/charts/kube-watcher \
  --set kollaber.env=prod \
  --set kollaber.api=https://kollaber.io \
  --set kollaber.existingSecret=my-kollaber-token

The watcher binary also works outside the cluster using your local kubeconfig — useful for testing:

go install github.com/urbangeeks/kollaber/cmd/kube-watcher@latest

kube-watcher \
  --kubeconfig ~/.kube/config \
  --env prod \
  --api https://kollaber.io \
  --token <cli-token>

The binary tries in-cluster config first. If it is not running inside a pod it falls back to --kubeconfig (or ~/.kube/config by default).

POST https://kollaber.io/webhooks/events

No authentication required on the webhook endpoint. Payloads are normalized into the events table.

Add a step at the end of your deploy job:

- name: Notify Kollaber
  run: |
    curl -sS -X POST https://kollaber.io/webhooks/events \
      -H "Content-Type: application/json" \
      -d '{
        "type": "deploy",
        "service": "${{ github.repository }}",
        "environment_id": "${{ secrets.KOLLABER_ENV_ID }}",
        "metadata": {
          "version": "${{ github.sha }}",
          "author": "${{ github.actor }}",
          "ref": "${{ github.ref }}"
        }
      }'

Store your environment UUID as a GitHub secret named KOLLABER_ENV_ID. Find it on the Dashboard under your environment settings.

Any JSON body with the following shape is accepted:

{
  "type":           "deploy" | "alert" | "note",
  "service":        "your-service-name",
  "environment_id": "uuid-of-environment",
  "metadata":       { /* any key-value pairs */ }
}

Add a webhook service and a template to argocd-notifications-cm. Argo CD builds the request body from a template you write, so this one is the contract — send the fields below and Kollaber will map them.

service.webhook.kollaber: |
  url: https://kollaber.io/webhooks/argocd?environment_id=<uuid>
  headers:
  - name: X-Kollaber-Secret
    value: $kollaber-webhook-secret

template.kollaber-sync: |
  webhook:
    kollaber:
      method: POST
      body: |
        {
          "app": "{{.app.metadata.name}}",
          "revision": "{{.app.status.sync.revision}}",
          "sync_status": "{{.app.status.sync.status}}",
          "health_status": "{{.app.status.health.status}}",
          "operation_phase": "{{.app.status.operationState.phase}}",
          "project": "{{.app.spec.project}}",
          "namespace": "{{.app.spec.destination.namespace}}"
        }

Then subscribe an Application with an annotation, for example notifications.argoproj.io/subscribe.on-sync-succeeded.kollaber.

Only app is required. The event status comes from operation_phase first and health_status second — a sync that succeeded onto a degraded app is recorded as a successful change, with the health left in the metadata. Add "type": "teardown" to the body on an on-app-deleted subscription; it defaults to deploy.

In the workspace, go to Settings → Notifications → Create a notification, choose Webhook, and use:

URL:      https://kollaber.io/webhooks/terraform?environment_id=<uuid>
Token:    your WEBHOOK_SECRET
Triggers: Completed, Errored

The token is used to sign the body with HMAC-SHA512, which Kollaber verifies against WEBHOOK_SECRET. The workspace name becomes the service.

Only runs that reached your infrastructure are recorded — applied as a success and errored as a failure. Plan, cancel, and discard notifications are accepted and skipped, so enabling extra triggers is harmless: a plan is not a change, and recording one would add a timeline marker for a run that touched nothing and count it as a deployment in DORA.

Add an apply webhook to your Atlantis server-side config, and send the secret as a header:

# repos.yaml
webhooks:
  - event: apply
    kind: http
    url: https://kollaber.io/webhooks/atlantis?environment_id=<uuid>

# server flag (or ATLANTIS_WEBHOOK_HTTP_HEADERS)
--webhook-http-headers='{"Authorization":"Bearer $WEBHOOK_SECRET"}'

Atlantis posts only after an apply has run, so every delivery is a real change. The service name is the project from atlantis.yaml, falling back to the directory and then the repository. The pull request number, branch, commit, and the user who ran atlantis apply are kept in the event metadata.

Use workspace-regex and branch-regex on the webhook to point different workspaces at different Kollaber environments.

Create an OIDC application and set the redirect URI to your Kollaber API origin plus /auth/sso/callback:

https://kollaber.io/auth/sso/callback

Self-hosted, this is derived from the API_URL environment variable, so set it to the origin your users reach. Request the openid and email scopes — the email claim is what Kollaber matches on.

Go to Settings → SSO and fill in the issuer URL, client ID, client secret, and the email domain your organization owns. Discovery is done against the issuer, so the issuer URL is the only endpoint you need to supply.

A domain can belong to one organization only — claiming one already registered elsewhere returns a conflict rather than silently redirecting your users into someone else’s tenant.

Users start the flow at your organization’s slug:

https://kollaber.io/auth/sso?org=acme

Kollaber redirects to the IdP, verifies the returned ID token, and issues its own JWT. The email claim must end in the configured domain — a token for someone@gmail.com against a config that owns acme.com is refused, so a misconfigured IdP that will authenticate anyone cannot become an open door into your timeline. An account is created on first sign-in if the email is new.

• Kubernetes cluster with Helm 3
• PostgreSQL 14+ (or use the in-cluster option below)

helm install kollaber oci://ghcr.io/urbangeeks/charts/kollaber \
  --namespace kollaber \
  --create-namespace \
  --set secret.jwtSecret=$(openssl rand -hex 32) \
  --set externalDatabaseUrl=postgres://user:pass@your-postgres:5432/kollaber \
  --set ingress.enabled=true \
  --set ingress.host=kollaber.mycompany.com

Save the generated jwtSecret — it must stay the same across upgrades or existing sessions will be invalidated.

If you don't have an external database, deploy one with Bitnami's chart:

helm install postgres oci://registry-1.docker.io/bitnamicharts/postgresql \
  --namespace kollaber \
  --set auth.username=kollaber \
  --set auth.password=changeme \
  --set auth.database=kollaber

Then use the service name as the hostname:

--set externalDatabaseUrl=postgres://kollaber:changeme@postgres-postgresql:5432/kollaber

Create a GitHub OAuth App at github.com/settings/developers. Set the callback URL to https://kollaber.mycompany.com/auth/github/callback, then pass the credentials:

--set secret.githubClientId=your_client_id \
--set secret.githubClientSecret=your_client_secret

If not set, GitHub OAuth is disabled and users log in with email/password only.

Kollaber uses email OTP for login — users receive a 6-digit code to sign in. Delivery is resolved in this order:

For production installs, configure SMTP:

--set secret.smtpHost=smtp.yourprovider.com \
--set secret.smtpPort=587 \
--set secret.smtpUser=notifications@mycompany.com \
--set secret.smtpPassword=your_password

SMTP uses STARTTLS on port 587. Port 465 (implicit TLS) is not supported. Most providers — Gmail, SendGrid, Mailgun, Exchange — support port 587.

--set secret.webhookSecret=your_hmac_secret

If not set, webhook payloads are accepted without signature verification.

If your cluster uses Istio instead of a standard ingress controller, disable the Ingress resource and enable Istio routing:

helm install kollaber oci://ghcr.io/urbangeeks/charts/kollaber \
  --namespace kollaber \
  --create-namespace \
  --set secret.jwtSecret=$(openssl rand -hex 32) \
  --set externalDatabaseUrl=postgres://user:pass@your-postgres:5432/kollaber \
  --set ingress.enabled=false \
  --set istio.enabled=true \
  --set istio.host=kollaber.mycompany.com

With TLS:

--set istio.tls.mode=SIMPLE \
--set istio.tls.credentialName=kollaber-tls

The gateway selector defaults to istio: ingressgateway. Override with --set istio.gatewaySelector.istio=my-gateway if your gateway pod uses a different label.

helm upgrade kollaber oci://ghcr.io/urbangeeks/charts/kollaber \
  --namespace kollaber \
  --reuse-values

Use --reuse-values to keep your existing secrets and config. Migrations run automatically on every upgrade.

Query parameters for GET /events: environment_id (required) and limit (default 50).

Query parameters for GET /events/:id/suspects: window_minutes (default 180, max 1440) and limit (default 5, max 20). Every suspect carries a score, a confidence, and the reasons that produced them — the ranking is a heuristic for ordering, never a causal claim.

Query parameters: q (required), environment_id (optional; org-wide if omitted), and limit (default 25, max 100). Each hit has a kind of event or comment; comment hits carry the event they were written on.

Query parameters: days (default 30, max 365) and environment_id. Time to restore is always org-wide; time_to_restore_scope in the response says so.

Query parameters for GET /decisions: environment_id, limit (default 50, max 200), and offset.

Query parameters: from and to (RFC3339 or epoch milliseconds, default the last 24 hours), environment_id, service, and type (comma-separated; defaults to every type except note).

Require the Team plan or higher. Responses need an Anthropic API key configured on the server.

Body: environment_id, from, to, and an optional narrative boolean. Unlike the AI routes above, the factual document is returned on every plan with or without an Anthropic key — only the narrative section is gated on Pro, and narrative_status in the response says which applied.

Caps at 500 events and 1000 comments per document; the response sets truncated when the window overflows the event cap.