Skip to main content

Fixed.sh

Private preview

Your team is getting a second set of eyes.

Fixed.sh is an AI workspace for investigating incidents and tickets, gathering evidence, and preparing safe fixes with humans in control.

~20 min – ~2 hrs typical triage saved per workflow across six ops scenarios.

Join the private preview Read the FAQ

Built for SREs, helpdesk agents, IT operators, and teams that want AI help without handing over the keys.

Repair: playbook queued for approval

Incident workspace

INC-2847 · API latency spike: checkout

P1 Investigating · 12m

6 sources · 4 hypotheses · 0% confidence

Signal map

Replica pool saturated after auth deploy.

db-replica-02 Likely root cause

PagerDuty api-gateway auth-svc db-replica-02 Fix ready
✓ Alert ✓ Correlate ✓ Ranked Review fix

Live signals

Checkout p95

+340ms

DB pool

98%

5xx rate

0.4%

Investigation log

  • 2m ago Drafted remediation plan: awaiting human approval
  • 5m ago Ranked replica saturation hypothesis (78% confidence)
  • 8m ago Linked auth-svc v2.14.1 deploy to DB load spike
  • 11m ago Opened from PagerDuty · checkout latency SLO burn

Evidence

  • DB pool 98% on db-replica-02

    High

  • auth-svc v2.14.1 deploy · 11m prior

    Medium

Inputs

Alerts Tickets Endpoints Logs +2

Awaiting approval

Scale read pool +1, drain replica-02. Risk: Low

Rank hypotheses, not tabs

Turn noisy alerts and scattered context into a focused trail with ranked leading causes.

Approve before anything changes

Review evidence, proposed fixes, and risk: repair playbooks wait for a human sign-off.

Carry what worked forward

Operational memory from every incident feeds the next investigation: not another blank search.

How it works

From alert to answer in three steps

Fixed meets your team where incidents and tickets already live: then keeps humans in the loop before anything changes.

01

Alert or ticket arrives

Fixed ingests the signal from PagerDuty, ServiceNow, EDR, or your monitoring stack.

02

Correlate and rank

Evidence, dependencies, and recent changes are linked into ranked hypotheses with confidence scores.

03

Review and approve

Your team gets an RCA brief or repair playbook: nothing runs until a human approves.

Human in the loop

Investigate or repair: always with approval

Fixed drafts RCA briefs and queues repair playbooks. Nothing executes until your team signs off.

investigate Human in the loop

Investigate mode

RCA briefs and ranked hypotheses ready for handoff: recommended next steps, no automated changes.

  • · VPN path degradation triage
  • · Host-down parallel triage
  • · EDR alert validation
repair Human in the loop

Repair mode

Approved playbooks queue behind human sign-off: raise limits, roll back, or isolate only after review.

  • · Checkout pool saturation response
  • · Intune cert rollout rollback

Your stack

Connects to the tools you already run

Integrations named across our workspace examples: your connectors in private preview may vary.

Active Directory CrowdStrike Datadog Microsoft Exchange GitHub Grafana Microsoft Intune Jaeger Okta PagerDuty Microsoft Configuration Manager ServiceNow Slack Splunk VMware vCenter

Private preview

What you get when you join

Early access is hands-on: we onboard a limited cohort and shape connectors around how your team actually investigates.

Connectors and features vary by environment: tell us what you run on the access request form below.

Built for teams that want AI help without handing over the keys.

Human approval required before repair playbooks run.

Designed around the tools ops teams already use: PagerDuty, ServiceNow, Datadog, Intune, and more.

Use cases

From alert to answer across your stack

Whether you run production, support users, or map what's connected, Fixed.sh meets teams where the work actually happens.

From the blog

AI, ML, and ops investigations

Research notes and product perspective on evidence-backed triage and human-in-the-loop remediation.

View all posts →

Questions before you join?

Quick answers about what Fixed is, what it is not, and how private preview works.

What is Fixed.sh?

Fixed.sh is an AI investigation workspace for ops teams. It correlates alerts, tickets, logs, and dependencies into ranked hypotheses and evidence: then drafts RCA briefs or repair playbooks for human review.

How is this different from a chatbot or generic AI assistant?

Fixed is built around incidents and tickets, not open-ended chat. It links sources into a structured workspace with confidence scores, timelines, and proposed next steps: grounded in your stack, not a blank prompt box.

Does Fixed automatically change production?

No. Repair playbooks queue behind explicit human approval. Investigate mode produces RCA and next steps only. Nothing executes until your team signs off.

What tools does it connect to?

Workspace examples reference tools like PagerDuty, ServiceNow, Datadog, Grafana, Intune, CrowdStrike, and Slack. Connectors available in private preview will depend on your environment: tell us what you run when you request access.

Who is the private preview for?

SRE, platform, IT ops, helpdesk, security, and on-call teams who want faster triage without handing remediation keys to an agent. We are onboarding a limited number of teams.

What happens after I request access?

We read every request personally. If there is a fit, we will email you with next steps: usually a short call to understand your stack and workflows.

Request private preview access

Tell us about your team. We onboard a limited number of SRE, IT ops, helpdesk, and on-call groups.

SRE & platform

Chase SLO burns with context

Typical manual triage

45–60 min

Fixed.sh

8m

Time saved

~50 min

repairapproved playbookHuman in the loop

Playbook: Checkout pool saturation response

Raise pool limit + enable traffic shed: runs only after an engineer approves the playbook.

Without Fixed

Jump between PagerDuty, Grafana, deploy logs, and Slack threads.

With Fixed

One workspace with ranked hypothesis, evidence, and a repair playbook ready to approve.

Connects to

PagerDuty Datadog Grafana GitHub

What happened

  • SLO burn alert fired on the checkout API: error budget down to 12%.
  • Fixed linked rising 5xx errors to postgres-primary connection pool exhaustion.
  • Deploy and saturation dashboards ingested; leading hypothesis ranked at 82% confidence.
  • Proposed fix awaiting approval: raise pool limit and enable traffic shed on checkout-svc.

Engineer reviews a ranked hypothesis and proposed fix: not a blank dashboard search.

9 sources linked82% confidenceInvestigatingFix risk: Medium

You are here: Review fix

Proposed repair

Raise pool limit + enable shed on checkout-svc.

Incident workspace

INC-1924 · SLO burn: checkout API errors

P1 Investigating · 8m

9 sources · 3 hypotheses · 82% confidence

Signal map

Connection pool exhaustion on primary after traffic shift.

postgres-primary Leading hypothesis

PagerDuty api-gateway checkout-svc postgres-primary Fix ready
✓ Page ✓ Correlate ✓ Ranked Review fix

Live signals

Error budget

12% left

5xx rate

2.8%

Pool wait

840ms

Investigation log

  • 1m ago Suggested pool resize + traffic shed: pending approval
  • 4m ago Matched latency spike to postgres connection metrics
  • 6m ago Ingested deploy + saturation dashboards for checkout path

Evidence

  • SLO burn alert fired · checkout API

    High

  • postgres-primary connections at max

    High

Inputs

Alerts Metrics Logs Traces +2

Awaiting approval

Raise pool limit + enable shed on checkout-svc. Risk: Medium

Helpdesk & service desk

Resolve tickets faster

Typical manual triage

20–30 min

Fixed.sh

6m

Time saved

~22 min

investigateRCA & next stepsHuman in the loop

Playbook: VPN path degradation triage

RCA and tier-1 guidance drafted: hypothesis ready to paste into the ticket.

Without Fixed

Ask the user to reboot, check Wi‑Fi, and escalate when nothing obvious shows up.

With Fixed

Structured RCA and next steps from endpoint, VPN, and path data: ready to paste into the ticket.

Connects to

ServiceNow Microsoft Intune Microsoft Exchange Okta

What happened

  • ServiceNow ticket opened: user reports Outlook is slow on laptop-8812.
  • Fixed parsed the vague report into endpoint health, VPN, and path checks.
  • VPN round-trip time is 3× baseline vs office peers: local Outlook profile looks fine.
  • Tier-1 workaround drafted: alternate VPN egress test; ready to share with the user.

Tier-1 gets a structured note with evidence: not back-and-forth guessing with the user.

5 sources linked71% confidenceInvestigatingFix risk: Low

You are here: Share RCA

Proposed next steps

Guide user to alternate VPN egress; escalate ISP if persists.

Incident workspace

TKT-8831 · "Outlook is really slow": Jane R.

P3 Investigating · 6m

5 sources · 2 hypotheses · 71% confidence

Signal map

VPN latency spike on home ISP path to Exchange edge.

vpn-client Likely root cause

ServiceNow laptop-8812 vpn-client exchange-edge RCA ready
✓ Ticket ✓ Endpoint ✓ Path test Share RCA

Live signals

VPN RTT

214ms

Packet loss

3.1%

Outlook CPU

41%

Investigation log

  • 1m ago Hypothesis ready: tier-1 note with split-tunnel test + ISP path
  • 3m ago Ran endpoint health + VPN hop trace from laptop-8812
  • 5m ago Parsed vague ticket into structured checks

Evidence

  • VPN RTT 3× baseline vs office peers

    High

  • No local Outlook profile corruption

    Medium

Inputs

Tickets Endpoints Identity Network +1

Hypothesis ready

Guide user to alternate VPN egress; escalate ISP if persists. Risk: Low

Discovery & topology

See what connects to what

Typical manual triage

60–90 min

Fixed.sh

15m

Time saved

~70 min

investigateRCA & next stepsHuman in the loop

Playbook: Regional dependency mapping

Blast-radius RCA and failover recommendation: operator decides whether to execute next steps.

Without Fixed

Manually trace CMDB entries, ticket notes, and dashboards service by service.

With Fixed

Live topology and blast radius built from fleet signals: shared before the war room scatters.

Connects to

Datadog Jaeger ServiceNow

What happened

  • Synthetic monitor flagged partial outage in the west region orders path.
  • Fixed built a live dependency map: lb-west → orders-api → redis-cluster → inventory-svc.
  • Blast radius spans 6 services; shared redis-cluster identified as the failure fan-out point.
  • Dependency map exported to the incident channel; blast-radius hypothesis ready for review.

Team sees blast radius before chasing the wrong service: map exported to the incident channel.

11 sources linked74% confidenceMappingFix risk: Medium

You are here: Share map

Proposed next steps

Fail over redis replica; notify dependent service owners.

Incident workspace

MAP-004 · Partial outage: west region orders

P2 Mapping · 15m

11 sources · 5 hypotheses · 74% confidence

Signal map

redis-cluster degradation fans out to orders + inventory APIs.

redis-cluster Blast radius

Synthetic lb-west orders-api redis-cluster inventory-svc RCA ready
✓ Detect ✓ Map deps ✓ Rank blast Share map

Live signals

Services

14 linked

Hosts down

3

Blast radius

6 svc

Investigation log

  • 2m ago Hypothesis ready: dependency map exported for incident channel
  • 7m ago Linked inventory errors to shared redis saturation
  • 12m ago Built live topology from fleet + ticket signals

Evidence

  • orders-api + inventory share redis-cluster

    High

  • lb-west only region with elevated 5xx

    High

Inputs

CMDB Tickets Metrics Traces +1

Hypothesis ready

Fail over redis replica; notify dependent service owners. Risk: Medium

IT operations

Investigate fleet-wide issues

Typical manual triage

2–3 hrs

Fixed.sh

22m

Time saved

~2 hrs

repairapproved playbookHuman in the loop

Playbook: Intune cert rollout rollback

Pause ring-2 and redeploy cert chain: blocked until IT ops approves the repair playbook.

Without Fixed

Export Intune reports, spot-check endpoints, and draft rollback steps in a doc.

With Fixed

Fleet scan, drift pinpointed to ring-2, and an approved rollback playbook waiting for sign-off.

Connects to

Microsoft Intune Microsoft Configuration Manager Active Directory

What happened

  • Intune certificate rollout failing on 18% of endpoints in ring-2 (842 machines).
  • Fixed pulled patch and cert status across the fleet and found config drift on 126 hosts.
  • TLS errors correlated to an expired intermediate chain: ring-1 healthy on the same policy.
  • Rollback script drafted; ring-2 pause recommended pending operator approval.

Fleet-wide drift isolated to one rollout ring: rollback ready before more endpoints fail.

8 sources linked85% confidenceInvestigatingFix risk: Low

You are here: Rollback

Proposed repair

Pause ring-2; redeploy chain + validate store.

Incident workspace

ROL-77 · Certificate rollout: 18% clients failing

P2 Investigating · 22m

8 sources · 3 hypotheses · 85% confidence

Signal map

Expired intermediate on ring-2 before auto-renew policy applied.

intune-ring-2 Likely root cause

Intune policy intune-ring-2 842 endpoints cert-store Rollback ready
✓ Rollout ✓ Fleet scan ✓ Drift found Rollback

Live signals

Failed

18%

Drift

126 hosts

Compliant

82%

Investigation log

  • 3m ago Drafted ring-2 pause + cert push rollback script
  • 10m ago Correlated TLS errors to expired intermediate chain
  • 18m ago Pulled patch + cert status across 842 endpoints

Evidence

  • Intermediate expired on ring-2 only

    High

  • ring-1 healthy · same policy version

    High

Inputs

MDM Endpoints Certs Patch +1

Awaiting approval

Pause ring-2; redeploy chain + validate store. Risk: Low

Security & compliance

Validate suspicious activity

Typical manual triage

30–45 min

Fixed.sh

9m

Time saved

~35 min

investigateRCA & next stepsHuman in the loop

Playbook: EDR alert validation

RCA scoped to FIN-22 with ranked hypothesis and recommended next steps: ready for analyst review.

Without Fixed

Pull EDR console, auth logs, and ticket history across three separate tools.

With Fixed

Scoped RCA on one host with evidence: ranked hypothesis ready for analyst review.

Connects to

CrowdStrike Splunk Okta ServiceNow

What happened

  • EDR alert on suspicious PowerShell execution on host FIN-22.
  • Fixed collected endpoint, auth, and command history logs around the alert.
  • Script is signed by a known helpdesk tool; no IoC hits or lateral movement on peer hosts.
  • Leading hypothesis ranked benign; RCA and next steps ready for analyst review.

Analyst validates scope with evidence first: hypothesis ready before any remediation is considered.

7 sources linked76% confidenceValidatingFix risk: Low

You are here: Review RCA

Proposed next steps

Close as benign; add allow rule if pattern repeats.

Incident workspace

SEC-119 · Suspicious PowerShell: FIN-22

P1 Validating · 9m

7 sources · 2 hypotheses · 76% confidence

Signal map

Signed script from helpdesk tool; no lateral movement observed.

FIN-22 Assessment

EDR alert FIN-22 user-session cmd history RCA ready
✓ Alert ✓ Triage ✓ Scope Review RCA

Live signals

Risk score

62

IoC hits

0

Hosts scoped

1

Investigation log

  • 2m ago Hypothesis ranked benign: RCA ready for analyst review
  • 5m ago Verified signer matches approved helpdesk package
  • 8m ago Collected endpoint + auth logs for FIN-22

Evidence

  • PowerShell signed · known helpdesk tool

    High

  • No peer hosts with same parent process

    High

Inputs

EDR Logs Identity Change history +1

Hypothesis ready

Close as benign; add allow rule if pattern repeats. Risk: Low

On-call rotation

Triage alongside the page

Typical manual triage

15–25 min

Fixed.sh

3m

Time saved

~20 min

investigateRCA & next stepsHuman in the loop

Playbook: Host-down parallel triage

RCA brief and recommended next steps posted for on-call handoff: hypothesis ready when they join.

Without Fixed

On-call pages in, opens five tabs, and starts searching from scratch.

With Fixed

Parallel RCA brief with dependencies and next steps waiting in the incident channel.

Connects to

PagerDuty VMware vCenter Datadog Slack

What happened

  • PagerDuty page sent for host down on prod-app-14: same alert opened in Fixed.
  • Fixed linked the outage to esxi-03 heartbeat loss in vCenter.
  • Four dependent services identified; no deploy or patch on prod-app-14 in the last 24h.
  • Investigation brief posted to #inc-prod-app-14 for on-call handoff.

On-call joins the bridge with a brief in hand: not a cold start at the search bar.

7 sources linked81% confidenceInvestigatingFix risk: Medium

You are here: On-call joined

Proposed next steps

Evacuate VMs on esxi-03; restore prod-app-14 on healthy host.

Incident workspace

INC-4471 · Host down: prod-app-14

P1 Investigating · 3m

7 sources · 2 hypotheses · 81% confidence

Signal map

Guest VM offline after ESXi host esxi-03 stopped responding.

prod-app-14 Leading hypothesis

PagerDuty prod-app-14 esxi-03 4 dependents RCA ready
✓ Page sent ✓ Fixed triage ✓ Ranked On-call joined

Live signals

Host status

Down

Ping loss

100%

Affected svc

4

Investigation log

  • 1m ago Hypothesis ready: brief posted to #inc-prod-app-14 for on-call handoff
  • 2m ago Linked prod-app-14 outage to esxi-03 heartbeat loss in vCenter
  • 3m ago Opened from PagerDuty · same page as primary on-call

Evidence

  • ICMP failed on prod-app-14 · esxi-03 unreachable first

    High

  • No deploy or patch on prod-app-14 in 24h

    High

Inputs

PagerDuty Metrics Logs CMDB +2

Hypothesis ready

Evacuate VMs on esxi-03; restore prod-app-14 on healthy host. Risk: Medium