Troubleshooting Cloudbrief

If your situation isn't here, email manish.gaud@bhavitech.com with the error message and (if possible) the run ID — typical reply window is one business day.

Connection issues

"AccessDenied" when adding an AWS account

The IAM role you created doesn't trust our principal, or the external-id doesn't match.

Check the trust relationship. The role's trust policy should be exactly:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::099547753263:user/analyzer-app-runtime"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "<EXTERNAL_ID_FROM_OUR_FORM>"
      }
    }
  }]
}

If you used the CloudFormation template, this is auto-populated. If you wrote the role by hand, double-check the external-id and the principal ARN.

"InvalidClientTokenId"

Your access keys are stale. The Cloudbrief side doesn't rotate AWS access keys — if you see this, our credentials need refreshing. Email us.

"Role does not exist"

You may have deleted the CloudFormation stack but left the AWS account connection in the app. Either re-create the role (re-run the CloudFormation template, paste the ARN back into the app) or delete the connection in Cloudbrief → AWS accounts.

Daily analysis didn't run

Quick checks:

Is daily_enabled true for the account? Check Cloudbrief → AWS accounts → click the account → settings. If false, the worker skips it.
Is the worker alive? Symptom: no heartbeat row in the logs for a long stretch. The worker emits a heartbeat every 60 seconds. If you have platform-owner access, Workspace → Platform admin → ... TBD UI for this. Otherwise email us; we'll check.
Did the worker fail at IAM assume? The next analysis will surface "AccessDenied" — check the report's status_message. Then go to the Connection issues section above.

Email recipient didn't get the report

Spam folder. SES emails sometimes go to spam initially. Mark as not-spam to train your provider.
Recipient configured? Email recipients are per AWS account. Check Cloudbrief → AWS accounts → click the account → "Edit recipients".
No recipients = no email by design. If the recipient list is empty, the report runs and is viewable in the UI but no email is sent. See Reports → Email recipients.
SES is in sandbox is not your concern — we're out of sandbox in ap-south-1. If still missing, email us and we'll trace the SES delivery log.

Reports are "All clear ✓" every day — am I missing things?

Probably not — most AWS accounts genuinely are quiet most days. But if you suspect a detector is failing to fire on something real:

Pick a concrete window when you know something interesting happened.
Email us the AWS account nickname + date range + what should have been caught.
We'll replay the detectors against historical data and either:
- Confirm the detector did fire and the LLM call happened (check Reports for the date), OR
- Find which threshold was just-above-the-firing-line and tune it

An investigation crashed mid-run

Open the Report — status should be failed and status_message should have the cause. Common causes:

AWS data collection timed out — usually an unusually large window. Try a narrower date range.
Anthropic rate-limit — we got 429'd. Retry in a few minutes.
Unexpected exception — the message will say "Processing failed unexpectedly". Email us with the report ID; we'll look at the worker log.

"Anthropic API key not configured"

The platform's Anthropic credit ran out or the key was rotated. We see this immediately on our end and refill — usually back to healthy within an hour. Email us if it persists.

Bills look wrong on Workspace → Usage

The numbers on the usage page are computed at write-time from the pricing table in the code. If the cost looks higher than the report would suggest, possibilities:

Investigations don't roll up to the daily report — each is its own LLM call with its own cost row.
OCR for Paperbrief is also on this page if you're using Paperbrief — it's labelled by product.

If after factoring those in the number still looks off, email us with the org name and we'll reconcile against the provider invoices.

I can't reach app.kashilabs.ai

Sanity check:

curl -sI https://app.kashilabs.ai/health
# expect: HTTP/2 200, body {"status":"ok"}

If the curl works but the browser doesn't, hard-reload (Cmd+Shift+R / Ctrl+Shift+R) — stale HTML caching has bitten us before despite no-cache headers.

If the curl fails, check status:

Cloudflare status — https://www.cloudflarestatus.com/ (opens in a new tab)
AWS Lightsail status (ap-south-1) — https://health.aws.amazon.com/health/status (opens in a new tab)

Otherwise email us. We don't have a status page yet — that's queued.

Architecture Introduction