Skip to content
obsmate
Integrations With and without How it works Interactive chat Security Pricing
Sign in Request a demo
Integrations With and without The report How it works Interactive chat Security Pricing Sign in

An alert is not an answer.

Obsmate works on top of the monitoring you already have. When an alarm fires, it reads the metrics, logs and recent changes behind it, rules out the wrong leads, and sends your on-call team the root cause with the evidence attached.

Works with AWS CloudWatch today. Reports in Google Chat, the Obsmate app or by voice. See integrations

Request a demo Read a sample report

DatabaseConnections ≥ 100

prod-orders-db, me-central-1, fired 10:04:07

Investigation time 1:52
  1. Alarm received From CloudWatch at 10:04:07
  2. Grouped related alarms 14 alarms, one incident
  3. Mapped what’s affected orders-api, checkout-web, payments-worker
  4. Read database metrics Connections 38 → 100 in 2 min
  5. Hypothesis ruled out: Database overloaded? Ruled out: CPU 41%, memory and IOPS normal
  6. Hypothesis ruled out: Network fault? Ruled out: services on the same subnets healthy
  7. Read CloudTrail and deploys orders-api v2.31 shipped at 10:02
  8. Read the code change Workers 4 → 20, pool of 10 each
  9. Hypothesis confirmed: Release exhausted the pool? Confirmed: 20 × 10 = 200 > limit of 100
  10. Verified every claim Confidence: high
  11. Sent report to Google Chat At 10:05:59
0s 30s 60s 90s
Root cause

Release v2.31 raised orders-api from 4 to 20 workers. At 10 connections each, that’s 200 connections against a database limit of 100.

Read the full report

Example investigation. Steps and timings are illustrative.

Keep your monitoring. Add the investigation.

Obsmate isn’t a new place to send logs. It sits between the alerts you already have and the people who respond to them, reads your data where it already lives, and sends back an answer.

Your tools

Alerts come in. Data is read where it lives.

Available now

  • AWS CloudWatchAlarms, metrics and logs
  • AWS CloudTrailChanges and API activity
  • Code repositoriesCommits behind each deploy

More alert sources coming soon

  • Datadog
  • Grafana
  • Prometheus
  • Azure Monitor

obsmate

  1. Receives the alarm
  2. Reads metrics, logs, changes and code
  3. Tests each possible cause
  4. Verifies the answer
  5. Sends the report

Read-only access. No log shipping. No agents.

Your team

Answers arrive where you already respond.

Available now

  • Google ChatReport in your team’s incident space
  • VoiceTalk the incident through, out loud
  • Obsmate appEvery incident, report and conversation

More channels coming soon

  • Slack
  • Email
  • Microsoft Teams
  • PagerDuty
Not a log platform
You don’t ship logs or metrics to Obsmate. It queries them in CloudWatch when an investigation needs them.
Not another dashboard
Reports arrive in Google Chat, the Obsmate app or a voice call, where your team already responds.
Not a replacement
Keep your monitoring and alerting. Obsmate adds the step between the alarm and the fix.

The same alarm, two different nights.

Here’s that incident handled by an on-call engineer working alone, and handled with Obsmate. Same alarm, same team, same fix. The difference is how long it takes to find it.

Without Obsmate 65 min customers affected
Waiting for ack Checking DB dashboards Scaling up the DB War room Finding the deploy Rollback
With Obsmate 9 min customers affected
Obsmate investigates for 2 min, the engineer reads the report, then rolls back.
10:04 10:19 10:34 10:49 11:04
  • Obsmate investigating
  • Engineer working
  • Waiting for someone
  • Wrong lead
  • Recovering
Timeline comparison: without Obsmate, the incident lasts 65 minutes, including 14 minutes spent scaling the database, which was the wrong lead. With Obsmate, it lasts 9 minutes.

On-call engineer, alone

  1. 10:04 Pager goes off. Checkout errors start.
  2. 10:11 Engineer acknowledges and opens the laptop.
  3. 10:11 Database dashboards show connections at the limit. Looks like load.
  4. 10:24 Scales the database up a size. Errors continue.
  5. 10:38 Opens a war room and pages the app team.
  6. 10:52 Someone notices a release went out at 10:02.
  7. 11:01 Worker count change confirmed. Rollback starts.
  8. 11:09 Recovered. The database upgrade stays on the bill.

On-call engineer, with Obsmate

  1. 10:04 Alarm fires. Obsmate starts investigating straight away.
  2. 10:06 Report arrives in the team’s Google Chat space: the release, the numbers, the fix.
  3. 10:09 Engineer checks the evidence links and starts the rollback.
  4. 10:13 Recovered. Nobody else was woken up.

Illustrative timeline of the example incident. Real times depend on your systems and team.

What your on-call engineer receives.

A report in your team’s incident space, written for the person who has to act on it. Every claim points to the data behind it.

INC-2041

Database connections failed after a release

Opened
10:04:07
Report sent
10:05:59
Severity
High
Confidence
High

Arrives within minutes of the alarm, before most engineers have opened a laptop.

Summary

From 10:04, checkout requests failed because orders-api could not open new database connections.

Plain language first. Anyone on the team can read one line and know what’s happening.

Root cause

Release v2.31 at 10:02 raised orders-api from 4 to 20 workers. Each worker opens up to 10 connections, so the service could open 200 connections against a database limit of 100.

One cause, stated with the numbers that prove it.

Evidence

  • Connections rose from 38 to the limit of 100 between 10:02 and 10:04.

    CloudWatch / prod-orders-db / DatabaseConnections

  • The orders-api desired count changed from 4 to 20 at 10:02:11.

    CloudTrail / ecs:UpdateService / deploy-bot

  • Commit 8f3c2e1 set WORKERS=20. Pool size per worker stayed at 10.

    your-org/orders-api / 8f3c2e1

Each finding links to the exact query, event or commit, so you can check it in one click.

Ruled out

  • Database overload. CPU peaked at 41%. Memory and IOPS stayed normal.
  • Network fault. Other services on the same subnets stayed healthy.

What it checked and rejected, so nobody spends the next hour on it.

Suggested next steps

  1. Roll back orders-api to v2.30 to bring connections back under the limit.
  2. Before redeploying, set the pool to 4 connections per worker: 80 in total at 20 workers.

Suggestions only. Obsmate has read-only access and never changes your systems.

Confidence: high

A separate verification pass re-checked every claim above against the source data.

When the evidence is thin, the report says so instead of guessing.

Between the alarm and the report.

Six steps run for every incident, without anyone starting them.

  1. Group

    Alarms arrive from AWS CloudWatch. Related ones become one incident, so a cascade of 14 alarms is one investigation.

  2. Map

    Obsmate knows how your services connect, from your cloud account and code repositories, and works out what is affected.

  3. Investigate

    An agent queries metrics, logs, CloudTrail, deploy history and code changes, forming hypotheses and testing each one.

  4. Verify

    A separate pass checks every claim against the source data and scores how confident the conclusion is.

  5. Deliver

    The report goes to Google Chat and the Obsmate app within minutes of the alarm. Follow-ups work in chat or by voice.

  6. Learn

    Your team’s feedback on each report shapes future investigations in your account.

Talk it through, by voice or chat.

Every incident stays open for questions. Call Obsmate and talk to it out loud when you’re away from your keyboard, or type in chat. Answers come back with the same evidence as the report, and Obsmate remembers past incidents in your account.

Voice to voice
Ask out loud and hear the answer. Useful on the way to your laptop at 3am.
Chat
Type follow-ups next to the report. Every answer links to its source.
Voice call with Obsmate 02:14

You What changed right before the alarm?

Obsmate Release v2.31 of orders-api went out at 10:02. It raised the workers from 4 to 20, which pushed connections past the database limit.

INC-2041 Database connections failed after a release

Why didn’t this break in staging?

Staging runs the same release, but its database allows 400 connections. At 20 workers × 10 it peaked at 200, under that limit.

RDS parameter group / staging-orders / max_connections = 400

Has this happened before?

Once. INC-1873 on 12 August: a worker count change on payments-worker hit the same limit. It was fixed by lowering the pool size.

Report INC-1873

Read-only, by design.

Obsmate needs to see your systems to investigate them. It never needs to change them.

Read-only access
Obsmate can describe, list and read. It cannot create, change or delete anything.
No agents to install
It connects through an IAM role in your account that you control and can revoke at any time.
Your account or ours
Use Obsmate as a hosted service.
Explicit scope
Each connection lists exactly what Obsmate can read, and every query it runs appears in the report.
obsmate-readonly-role.json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ObsmateReadOnly",
    "Effect": "Allow",
    "Action": [
      "cloudwatch:GetMetricData",
      "cloudwatch:DescribeAlarms",
      "logs:GetQueryResults",
      "cloudtrail:LookupEvents",
      "ecs:DescribeServices",
      "rds:DescribeDBInstances",
      "config:GetResourceConfigHistory"
    ],
    "Resource": "*"
  }]
}

An excerpt of the role. No Create, Put, Update or Delete actions.

Priced by incident, not by seat.

Your whole team can read reports and ask questions on every plan. Start free.

Free

$0 for 1 month

  • 5 incidents included
  • $5 chat and voice budget

Pay as you go

$6 per incident

  • No monthly commitment
  • Chat and voice paid from credits

Team

$249 per month

  • 50 incidents included, then $5 each
  • $10 per month chat and voice credit

Business

$799 per month

  • 200 incidents included, then $4 each
  • $25 per month chat and voice credit

Grouped alarms count as one incident. Usage beyond a plan’s allowance is paid from credits at pay-as-you-go rates.

Compare plans in detail
Request a demo

See it investigate alarms like yours.

Tell us a little about your setup. We’ll walk you through Obsmate on incidents similar to the ones your team handles.

  • Read-only from day one
  • No agents to install
  • 5 free incidents to start

Enter your full name.

Enter a work email, like name@company.com.

Enter your company name.

Choose your country.

Enter your number with the country code, like +962 79 000 0000.

We use these details only to arrange your demo. See our privacy policy.

obsmate

Root cause and evidence for every alarm.

Product

Integrations With and without The report How it works Voice and chat Security Pricing

Get started

Request a demo Sign in

Legal

Privacy policy Terms of service

© 2026 Obsmate. All rights reserved.