Sazabi

npx add-mcp 'https://mcp.sazabi.com/mcp'

AI-native observability and security

Quickstart: https://docs.sazabi.com/get-started/quickstart

Get started: npx @sazabi/cli start

Autonomous alerts, conversational debugging, and coding agent integrations. Sazabi surfaces the issues that matter and gives your team the context to resolve them.

Trusted by

• Mastra
• Weave
• Sandstone
• Wajo
• Autumn
• Agree.com
• Inth
• Hoplite
• Taiga
• XMTP Labs

Sazabi is an AI-native observability and security platform for teams that ship software quickly. It connects production logs with code, detects important issues without hand-built monitors, investigates root causes, and sends useful context to the tools where engineers work. Ask questions in plain language, understand what changed, and let coding agents use that context to help resolve production problems.

Use Sazabi for autonomous alerts, conversational debugging, and coding agent workflows. Sazabi is built for engineering teams that need to find and fix production issues without maintaining a large collection of dashboards and static monitors. Explore the product, integrations, security practices, and developer resources to learn how Sazabi fits your stack.

Capabilities

Zero-touch detection

Catch the issues you didn't plan for

Monitors only catch the failures you predicted. Sazabi watches every log and flags the rest, from silent outages and frustrated users to agents going off the rails, starting the minute you connect.

• Automatic detection: Find changes in your logs without writing alert rules.
• Root-cause analysis: Group related errors and trace them back to your code.
• Suggested fixes: Give engineers and coding agents a plan to resolve each issue.

Security monitoring

Know the moment you're exposed

Sazabi scans your code for security gaps and tells you as soon as a new CVE hits something you run. When botnets, fraud or intruders show up in your logs, your team hears about it in real time.

• Code scanning: Find vulnerabilities in your connected repositories.
• CVE tracking: Know when a new vulnerability affects your dependencies.
• Threat detection: Spot botnets, fraud and suspicious activity in your logs.

Plain-language search

Logs built for your agents

Your coding agents debug by reading logs, so Sazabi keeps all of them and makes them fast to search. Storage is cheap enough that you never have to choose what to throw away.

• Plain-language search: Ask a question and get an answer with matching log records.
• Structured queries: Search log fields and recurring patterns to narrow an investigation.
• CLI & MCP: Let coding agents query production logs from their own tools.

Always-live dashboards

Chart anything you already log

If it's in your logs, you can put it on a live dashboard: p99 latency, memory, slow queries, signups. You skip the metrics pipeline entirely.

• AI-generated dashboards: Describe what you want to track and turn your logs into charts.
• Log-based metrics: Chart log volume, memory and CPU from the data you already send.
• Live updates: Keep charts current as new logs arrive.

How Sazabi works

1. Connect GitHub and Slack: Install the GitHub and Slack apps in a few clicks. Sazabi reads your codebase for context and joins the channels where your team already works.
2. Send Logs: Forward logs from the platforms you already use. Structured or unstructured, Sazabi takes them as they are. No schemas, parsing rules, or dashboards to build.
3. Get Alerts: Sazabi watches your logs for anomalies, investigates each one against your code, and delivers the issue to Slack, Microsoft Teams, or email with the root cause already identified.

Surface issues from hundreds of signals

Attack attempts

Authentication anomalies

Failed-login bursts, credential stuffing, impossible travel, session reuse.

Issue type: Active attack (Credential stuffing, scanning, exploitation attempts.)

Credential stuffing across 900 accounts

Status: Open

Description

A coordinated login attempt is testing credentials across hundreds of accounts while rotating its source addresses.

What happened

Authentication logs contain 2,000 failed logins against 900 accounts. The same account sequence appears across different IPs, unlike the scattered mistakes in normal sign-in traffic. The failures indicate an automated takeover attempt; they do not establish that any account was accessed.

How to investigate

Group attempts by account and session fingerprint, inspect any successful logins in that set, and rate-limit the abusive traffic.

Attack payloads

SQL injection, path traversal, SSRF or template injection attempts in requests.

Issue type: Active attack (Credential stuffing, scanning, exploitation attempts.)

SQL injection probes against an observability tool

Status: Open

Description

Unauthenticated SQL injection probes reached the database through a self-hosted observability tool and escaped the team’s error tracking.

What happened

Someone with no session sent SQL injection probes to a self-hosted observability tool that passed them straight to its database. The team’s error tracking never saw them; they looked like a few failed requests.

How to investigate

Trace the affected request path and review database query logs for unauthorized access. Check the exposed tool’s version and restrict ingress while investigating.

Exploit attempts

Traffic that matches a known exploit against your stack.

Issue type: Active attack (Credential stuffing, scanning, exploitation attempts.)

Probes for a vulnerable endpoint

Status: Open

Description

Requests are targeting the endpoint named in a new security advisory, putting the deployed application’s exposure into question.

What happened

Access logs show repeated probes with the route and payload shape described by the advisory. These requests bypass ordinary navigation and go directly to the affected endpoint. Matching traffic establishes an attempted exploit, but neither a vulnerable deployment nor successful execution is confirmed.

How to investigate

Compare the deployed package version and enabled routes with the advisory, then inspect responses and downstream effects before deciding whether patching or containment is needed.

Bots and scraping

High-rate clients, headless browsers, rotating IPs.

Issue type: Abuse and fraud (Promo or referral abuse, fake signups, spam, scraping.)

Directory being scraped

Status: Open

Description

Automated clients are walking the company directory in order, creating sustained read load and collecting profile data in bulk.

What happened

Requests from one network traverse every directory page with regular spacing and no intervening navigation. Rotating client addresses share the same page sequence and request shape. The activity differs from interactive browsing and exposes the directory to systematic collection.

How to investigate

Review which fields are publicly readable, group the clients by behavior, and apply directory-specific rate limits without blocking ordinary browsing.

Suspicious access

Access anomalies

One actor reads far more data than normal, or walks through IDs in sequence.

Issue type: Suspicious access (Compromised accounts, insider misuse, data exfiltration.)

Records read in sequence

Status: Open

Description

One authenticated account is enumerating thousands of records instead of following its usual browsing pattern.

What happened

The account requests record IDs 1 through 5,000 in sequence. Successful reads continue across records the session did not reach through search or navigation. This indicates bulk collection and warrants checking the access scope before assuming that every returned record was authorized.

How to investigate

Inspect the session, its expected workload and record-level authorization decisions. Revoke access if unauthorized and identify which records were returned.

Privilege changes

New admins, role escalations, new API keys.

Issue type: Suspicious access (Compromised accounts, insider misuse, data exfiltration.)

Admin role granted at 3am

Status: Open

Description

An account received administrator privileges from an unfamiliar location outside its normal activity, creating a new path to privileged operations.

What happened

The audit trail records an admin grant at 3am from a location not present in the actor’s earlier sessions. Subsequent access uses the new role. The grant could be legitimate maintenance, but its actor, timing and scope need verification before the privilege is trusted.

How to investigate

Confirm the grant with the account owner, inspect the authorizing session and review subsequent privileged actions. Revoke the role if it was not approved.

Unusual data egress

Large exports or responses to a single actor.

Issue type: Suspicious access (Compromised accounts, insider misuse, data exfiltration.)

Export 50x larger than usual

Status: Open

Description

An export is moving substantially more data than this account normally retrieves, raising the possibility of accidental or unauthorized bulk access.

What happened

A CSV response is 50 times larger than the account’s usual exports. The request removes the filters used in earlier exports and returns a much broader record set. The size change establishes unusual egress; authorization and intended scope still need to be checked.

How to investigate

Compare the export filters, returned fields and account permissions with the requested task. Review the destination and revoke the session if the export was unauthorized.

Rogue agents

AI agents, yours or a third party's, act outside their normal scope.

Issue type: Agent misbehavior (AI agents acting out of scope, prompt injection, runaway loops.)

Support agent calling an admin endpoint

Status: Open

Description

A support agent is invoking an administrative operation outside the tools and scope used for its normal support tasks.

What happened

Tool-call logs show the agent reaching an admin endpoint it has never used before. The call follows customer-supplied content rather than an operator instruction. That sequence raises a possible scope violation; the response and audit log must establish whether the operation actually changed anything.

How to investigate

Inspect the triggering content, tool arguments and authorization result. Restrict the agent’s tools to its support scope and require approval for administrative actions.

Vulnerabilities

Secrets or personal data in logs

Tokens, keys, emails or ID numbers written to logs.

Issue type: Exposure (A CVE that affects you, a vulnerable code path, a misconfiguration, leaked secrets.)

API key printed in an error

Status: Open

Description

An error handler is copying a credential into diagnostic output, exposing it to systems and people with log access.

What happened

A failed outbound request includes its API key in the logged error message. The value is propagated with the exception instead of being redacted at the logging boundary. Anyone able to read that record may be able to reuse the key until it is revoked.

How to investigate

Revoke the exposed key, identify where the record was delivered and retained, and redact credentials before serializing request errors.

New advisory affecting you

A newly published CVE matches your dependencies or runtime (via cve.now).

Issue type: Exposure (A CVE that affects you, a vulnerable code path, a misconfiguration, leaked secrets.)

New advisory matches your lockfile

Status: Open

Description

A newly published framework advisory includes the version pinned in the application’s lockfile, requiring an exposure check against the deployed build.

What happened

The advisory’s affected-version range matches the resolved framework dependency. The lockfile match identifies a potentially vulnerable artifact, but does not show whether the affected feature is enabled or reachable. The deployed build and its route configuration determine the actual exposure.

How to investigate

Verify the deployed version and affected feature, review the advisory’s mitigations, then upgrade to a fixed version and exercise the relevant route.

Risky code

Code scanning flags missing auth checks, auth bypasses or injection risks in new commits.

Issue type: Exposure (A CVE that affects you, a vulnerable code path, a misconfiguration, leaked secrets.)

Host files leaking into deploy errors

Status: Open

Description

Deploy failures exposed files from the builder host to users through error messages that appeared to be ordinary parse failures.

What happened

A deploy builder read files off its own host and returned them to users inside deploy error messages, including /etc/passwd-style content. On the surface these were failed deploys with a parse error.

How to investigate

Trace how build input can reach host files and error output. Review file extraction boundaries and remove host-file contents from user-visible errors.

Supply chain

A dependency changes hands, gets typosquatted or is flagged malicious.

Issue type: Exposure (A CVE that affects you, a vulnerable code path, a misconfiguration, leaked secrets.)

Compromised package version

Status: Open

Description

A dependency release has been flagged as compromised, and the lockfile indicates that it may be included in application builds.

What happened

The flagged package version matches the resolved dependency rather than just a permissive version range. Build records need to establish where that version was installed and whether its code or install scripts ran. The match creates an exposure risk without proving that credentials or data were taken.

How to investigate

Identify affected builds, compare the package with the trusted release, replace it, and rotate credentials only where execution could have exposed them.

Log patterns

Vanished event

Something that normally happens has stopped, while traffic is normal.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

Applications stopped arriving

Status: Open

Description

Application submission events stopped while users continued reaching the form, suggesting that work is being lost without an explicit error.

What happened

The “Application submitted” event disappears after 2:14pm while form views and submit attempts continue. The usual completion event no longer follows those attempts. Traffic alone looks healthy, but the missing transition means applications may not be reaching their stored state.

How to investigate

Trace a submit attempt through validation, persistence and event emission. Compare stored applications with attempts to separate a logging gap from lost submissions.

Volume shift

An event's rate jumps or drops far outside its normal pattern.

Issue type: Abuse and fraud (Promo or referral abuse, fake signups, spam, scraping.)

Password reset surge

Status: Open

Description

Password reset requests are substantially above their usual weekly pattern, increasing email load and potentially flooding account owners with unwanted messages.

What happened

Reset email events run at six times their normal Tuesday rate while ordinary sign-in traffic stays near its baseline. Repeated target accounts and similar request sequences account for much of the increase. This points to abuse or an accidental retry loop rather than broad user growth.

How to investigate

Group requests by target account and initiator, check for a client retry loop, and enforce per-account reset limits on abusive traffic.

Broken sequence

A is normally followed by B; now A happens without B.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

Uploads never complete

Status: Open

Description

Upload requests begin normally but fail to reach their completion step, leaving files unavailable even though users have started the transfer.

What happened

“Upload started” records continue to arrive, but their request IDs have no matching “upload complete” event. The missing completions cluster after the storage handoff. Users are left waiting for a file that has not been finalized, without a corresponding application error.

How to investigate

Follow the affected upload IDs through storage and finalization. Check for abandoned multipart uploads, failed callbacks and missing timeout or error handling.

Order or timing change

Steps happen out of order or with longer gaps.

Issue type: Data integrity (Lost writes, duplicates, corruption, mismatched records.)

Webhooks processed before their records

Status: Open

Description

Webhook processing is racing the creation of the record it updates, allowing an otherwise valid event to be discarded as missing data.

What happened

Webhook handlers look up a record before the corresponding creation transaction commits. The lookup returns nothing, but a later read finds the record with no webhook update applied. The event ordering leaves the local state behind the provider even though both requests finish.

How to investigate

Correlate webhook receipt with transaction commits, retain unmatched events for retry, and make replay safe once the target record exists.

Field drift

Values inside events shift: new categories, nulls, empty strings, unusual sizes.

Issue type: Data integrity (Lost writes, duplicates, corruption, mismatched records.)

Writes missing their company

Status: Open

Description

A subset of writes is losing its company association, creating records that cannot be reliably attributed or retrieved in the expected scope.

What happened

The company_id field is null on 3% of writes that previously carried a value. Those records share an input path that omits company context before persistence. The writes succeed, but downstream company-scoped reads can no longer find them in the expected collection.

How to investigate

Trace how company context reaches that write path, reject missing required ownership fields, and identify affected records before attempting a scoped repair.

Cardinality jump

A field suddenly has far more distinct values.

Issue type: Capacity risk (Heading for a limit before it bites.)

Cache keys multiplying

Status: Open

Description

The cache is creating new keys for otherwise similar requests, reducing reuse and increasing storage pressure.

What happened

Thousands of distinct cache keys appear each minute for the same small set of routes. Keys vary in a request-specific suffix, so repeated requests miss entries that should be reusable. The growing key set increases memory use while pushing more work onto the backing service.

How to investigate

Compare old and new key construction, remove unintended request-specific fields, and verify expiry before cleaning up unreachable entries.

Quiet failure wording

Events that describe a failure but are logged as info or debug.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

Pricing update skipped the biggest account

Status: Open

Description

A pricing job treated a skipped account as successful completion, leaving the largest account’s users on the previous credit costs.

What happened

A job applying pricing changes skipped the largest account because of a hard-coded cap, then reported “completed”. The skip was logged as info, so that customer’s users kept paying old credit costs.

How to investigate

Review the cap and skipped-account handling, rerun the update for the excluded account, and verify applied prices before recording completion.

Retry storm

The same operation retried in tight loops.

Issue type: Background job failure (Missed, duplicated, stuck or empty scheduled work.)

Job retrying in a tight loop

Status: Open

Description

A background worker repeatedly retries the same failing records without making progress, consuming capacity that other jobs need.

What happened

One job attempts each affected record 30 times in a tight loop. The error and input remain unchanged between attempts, and there is no growing delay. Repeated failures occupy the worker instead of allowing independent records to proceed or surfacing the blocked work.

How to investigate

Classify the repeated error as transient or permanent, apply bounded backoff, and move exhausted records to a reviewable failed state.

Correlation break

Two services that normally move together diverge.

Issue type: Background job failure (Missed, duplicated, stuck or empty scheduled work.)

Workers stopped keeping up

Status: Open

Description

API traffic is rising without a corresponding increase in worker completions, suggesting that accepted work is no longer reaching or leaving the queue.

What happened

The API continues accepting requests while completed worker jobs remain flat. Previously, the two counts moved together. The divergence means successful API responses no longer demonstrate that the requested background work finished, and a queue or dispatch failure may be hidden between them.

How to investigate

Compare accepted, enqueued, started and completed counts by job ID to locate the break before replaying or scaling work.

Novel event

A kind of event that has never appeared before.

Issue type: Regression (Behavior broken by a specific deploy or config change.)

Drafts skipped after deploy

Status: Open

Description

A new save path is skipping locked drafts after a release, leaving users’ edits unapplied without raising an exception.

What happened

The message “skipping save, draft locked” first appears after the deploy. Affected requests return without the normal persisted-draft event, while later reads still show the previous revision. The new branch is preventing the save rather than simply adding diagnostic logging.

How to investigate

Review the lock check introduced by the release, inspect stale lock cleanup, and verify that a rejected save is clearly reported to the user.

User behavior

Action without effect

A click with no server request, or a request with no persisted result.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

Connected screen, no token

Status: Open

Description

The account connection flow showed success even though its OAuth token was never persisted, leaving the connection unable to authenticate.

What happened

A user connecting an account saw “connected”, but the OAuth token was never saved. A duplicate callback sent them to the success page while the original request failed in the background.

How to investigate

Check the original and duplicate callback outcomes together. Only report connection success after the token is stored, then reconnect affected accounts.

Rage and repeat clicks

The same control clicked over and over.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

Users hammering Save

Status: Open

Description

Users repeatedly press Save because the form does not confirm whether their changes were accepted, encouraging retries that may duplicate work.

What happened

The same control is clicked five times in ten seconds within a session. The first request remains pending while subsequent clicks start more requests, and no success or failure state replaces the form. The interaction pattern suggests a stalled save or missing feedback.

How to investigate

Trace the first save request, surface its pending and failure states, and prevent duplicate submissions while checking that retries remain safe.

Funnel drop

Step-to-step conversion falls.

Issue type: Business flow breakage (A drop in a key metric with a technical cause.)

Signup completion fell to 50%

Status: Open

Description

More people are starting signup than completing it, with the loss concentrated between form submission and account creation.

What happened

Signup completion falls from 80% to 50% while the number of started sessions remains comparable. Sessions reach the submission step but lack an account-created event. The drop reflects incomplete onboarding rather than simply fewer visitors reaching the site.

How to investigate

Compare failed and successful signup traces at the first missing step, then segment by validation result, client version and identity provider.

Navigation loops

Users bounce between the same pages.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

Users stuck between settings and billing

Status: Open

Description

Users are being sent back and forth between settings and billing without reaching the screen needed to finish their task.

What happened

Sessions repeatedly follow settings → billing → settings with no intervening completion event. Each destination sends the user back based on a different account-state check. The loop prevents access to billing controls even though both routes return successful responses.

How to investigate

Compare the access conditions and account state used by both routes. Resolve the conflicting redirects and verify the journey from an affected session.

Dead ends

Sessions end on error states, blank screens or endless spinners.

Issue type: Frontend breakage (Broken for a specific browser, device or app version.)

Dashboard spinner never resolves

Status: Open

Description

The dashboard remains in its loading state until users leave, hiding a stalled request instead of presenting usable content or an error.

What happened

Sessions show the dashboard spinner for more than 30 seconds before the tab closes. The initial data request never produces a rendered success or failure state. Other page assets load normally, narrowing the failure to the data-loading path rather than a full page outage.

How to investigate

Inspect the pending request and the component’s error boundary, add a recoverable timeout state, and confirm that failed loads let the user retry.

Client errors

JavaScript exceptions, failed fetches, hydration errors.

Issue type: Regression (Behavior broken by a specific deploy or config change.)

New TypeError after release

Status: Open

Description

A newly released page throws a TypeError during rendering, preventing affected users from reaching its content.

What happened

The exception first appears in sessions using the new release and shares one stack location. The failing code reads a property from a missing response object before rendering the page. Requests can succeed at the network layer while the interface still fails to display their result.

How to investigate

Map the stack to the released source, inspect the response shape in affected sessions, and handle the missing value before rendering.

Web vitals regression

Page load and responsiveness get worse.

Issue type: Performance degradation (Slower pages, jobs or APIs, sudden or gradual.)

Interaction latency doubled

Status: Open

Description

Interactions on one page take noticeably longer to produce a visual response, even though the server still responds normally.

What happened

Interaction latency on the page doubles relative to its earlier baseline. Browser traces attribute the additional wait to long main-thread work after user input, while network timings remain comparable. Users experience a delayed interface without a corresponding API error or latency spike.

How to investigate

Profile the long task following input, compare the changed render path, and move or reduce synchronous work before measuring responsiveness again.

Segment-specific behavior

Only one browser, OS, app version, region or customer is affected.

Issue type: Frontend breakage (Broken for a specific browser, device or app version.)

Checkout failing on Safari 18

Status: Open

Description

Checkout fails for Safari 18 sessions while other browsers complete the same flow, hiding the regression in the overall success rate.

What happened

Failed checkout sessions are concentrated in Safari 18. Their client traces stop before the payment request, while the same cart reaches payment in other browsers. The browser-specific break prevents purchases without creating a matching payment-provider failure.

How to investigate

Reproduce the failing interaction in Safari 18, inspect browser API compatibility and client exceptions, then verify the fix against the working browsers.

Deploys and config

Post-deploy shift

Any other signal that starts within minutes of a deploy, tied to the commit.

Issue type: Regression (Behavior broken by a specific deploy or config change.)

Funnel dropped right after release

Status: Open

Description

A release coincides with fewer completed user journeys and a new rejection event, linking the regression to a changed request path.

What happened

Four minutes after the release, a previously unseen validation event appears and funnel completion falls. Failed sessions reach the same step and carry the new build identifier; sessions on the previous build still complete. The comparison points to the released path as the next place to investigate.

How to investigate

Compare validation and response handling between the two builds. Reproduce the affected input and evaluate rollback while isolating the change.

Config or flag change

Behavior changes after a feature flag, environment variable or infra change.

Issue type: Regression (Behavior broken by a specific deploy or config change.)

Flag rollout breaking saves

Status: Open

Description

A partially enabled feature flag is sending a subset of saves through a failing path while the rest of traffic continues normally.

What happened

The flag is enabled for 10% of traffic, and failed saves account for the same share. Failure records belong to the enabled cohort; the disabled cohort still persists changes. The rollout boundary provides a direct comparison for locating the regression.

How to investigate

Disable the affected flag cohort, compare the two save paths, and verify persisted results before expanding the rollout again.

Dependency change

An upgraded package lines up with new behavior.

Issue type: Performance degradation (Slower pages, jobs or APIs, sudden or gradual.)

Slow queries after ORM upgrade

Status: Open

Description

An ORM upgrade changes how a common read is executed, making requests slower without changing the amount of data users ask for.

What happened

Slow-query records begin with the upgraded build and cluster around one generated query. The previous version uses a different query shape for the same input, while request volume stays comparable. The dependency change is a plausible cause of the new database work.

How to investigate

Compare generated SQL and query plans across ORM versions, inspect the changed loading behavior, and test a corrected query or dependency rollback.

Error swallowing added

A commit adds catch-all error handling on an important path.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

Controller hides every exception

Status: Open

Description

A controller now converts failed operations into successful responses, preventing callers and error monitoring from recognizing that work was not completed.

What happened

The changed controller wraps its main operation in a catch-all handler that returns success. Request traces include an exception before the response, but no corresponding persisted result. The new handler masks failures instead of recovering from them, so users can lose changes without seeing an error.

How to investigate

Review the catch-all branch, preserve failure responses for unsuccessful operations, and verify that success is returned only after the write completes.

Migration effect

A schema migration changes query behavior.

Issue type: Performance degradation (Slower pages, jobs or APIs, sudden or gradual.)

Queries 20x slower after migration

Status: Open

Description

A schema migration removes the index used by a frequent query, increasing its execution time and slowing the requests that depend on it.

What happened

The affected query takes 20 times longer after the migration. Its plan changes from an indexed lookup to a broad scan, while the request shape is unchanged. The missing index makes each request examine far more rows and increases database work under normal traffic.

How to investigate

Compare the migration and query plans, confirm the required index shape, and restore an appropriate index using the database’s safe migration procedure.

Performance

Latency step change

A sudden jump.

Issue type: Regression (Behavior broken by a specific deploy or config change.)

Page load jumped to 1.2s

Status: Open

Description

Page loads became four times slower immediately after a deployment, adding a visible wait to an otherwise successful user flow.

What happened

Page-load duration shifts from 300ms to 1.2s after the deploy. Request traces show the increase in the server-side data-loading span rather than asset downloads. Responses still succeed, so error counts alone miss the slower experience.

How to investigate

Compare the data-loading code and query timings across the deploy, then verify the slow path with the same request input.

Gradual latency drift

Slow creep over days or weeks that no one notices.

Issue type: Performance degradation (Slower pages, jobs or APIs, sudden or gradual.)

Search slowing every week

Status: Open

Description

Search is becoming slower a little at a time, accumulating a user-visible delay that does not appear as a single incident spike.

What happened

Comparable searches take about 5% longer each week. The drift persists after accounting for request volume and is concentrated in the data lookup rather than response transfer. Growing work per query is a possible cause, even though no single deployment explains the trend.

How to investigate

Compare query plans, rows examined and index size across the baseline periods. Check whether data growth has changed the cost of the common search path.

Tail latency

Only the slowest requests get worse.

Issue type: Performance degradation (Slower pages, jobs or APIs, sudden or gradual.)

p99 latency tripled

Status: Open

Description

The slowest requests are taking much longer while typical requests remain fast, masking a degraded experience for a smaller group of users.

What happened

p99 latency triples while the median stays flat. Slow traces spend most of their extra time waiting for a shared resource before execution. Aggregate averages conceal those waits, but affected requests remain blocked long enough to risk client timeouts.

How to investigate

Group slow traces by resource and workload, compare their wait time with execution time, and inspect contention before increasing capacity.

Slow query emergence

A new slow query, or a new N+1 pattern.

Issue type: Performance degradation (Slower pages, jobs or APIs, sudden or gradual.)

One page making 400 queries

Status: Open

Description

A page is issuing a separate database lookup for each displayed item, increasing response time and database load as the list grows.

What happened

One page request now executes 400 queries with the same statement shape and different record IDs. The repeated reads occur serially after the initial list query. This N+1 pattern adds work proportional to the number of displayed items instead of fetching the related data together.

How to investigate

Trace the per-item lookup, batch or join the related reads, and compare query count and response time with a representative list.

Boot and cold-start creep

Services take longer to start.

Issue type: Capacity risk (Heading for a limit before it bites.)

Deploys slow to become healthy

Status: Open

Description

New instances take longer to become ready, slowing deployments and reducing how quickly the service can respond to additional demand.

What happened

The interval from process start to healthy readiness is three times its previous baseline. Startup logs show the extra delay before initialization completes, while steady-state request latency remains similar. Rollouts and scale-outs therefore spend longer waiting for usable capacity.

How to investigate

Break startup into dependency loading, initialization and readiness checks, compare each phase with the earlier build, and remove unnecessary work from the readiness path.

Queue wait growth

Work waits longer before it starts.

Issue type: Background job failure (Missed, duplicated, stuck or empty scheduled work.)

Emails going out 20 minutes late

Status: Open

Description

Email jobs are waiting in the queue long before execution, delaying messages even though delivery itself still succeeds.

What happened

The gap between an email trigger and the send attempt grows to 20 minutes. Once a worker starts a job, processing and provider response times remain normal. The delay lies before execution, so successful delivery counts alone do not reveal that messages arrive late.

How to investigate

Compare queue age, worker concurrency and competing job types. Remove the bottleneck or separate urgent mail while preserving safe retry behavior.

Infrastructure

Approaching a limit

Cloud quotas, burst credits, API rate limits, file handles, plan limits.

Issue type: Capacity risk (Heading for a limit before it bites.)

Burst credits running out

Status: Open

Description

File-system burst credits are being consumed faster than they recover, putting startup and other storage-heavy work at risk of throttling.

What happened

The credit balance declines across successive intervals as reads exceed the provisioned baseline. New-instance startup overlaps those reads and is sensitive to available throughput. The trend indicates limited remaining burst capacity, rather than proving the volume has already been throttled.

How to investigate

Compare storage throughput with its baseline and credit recovery rate, identify the dominant readers, and adjust provisioning or startup I/O before credits are exhausted.

Saturation

CPU, memory, connection pools, thread pools, disk.

Issue type: Capacity risk (Heading for a limit before it bites.)

Connection pool nearly full

Status: Open

Description

The database connection pool has little headroom during traffic peaks, causing requests to wait before they can execute a query.

What happened

Pool utilization reaches 95% at peak load and connection-acquisition waits rise alongside it. Query execution time remains comparatively stable once a connection is available. The contention is at the pool boundary and can turn normal request bursts into timeouts.

How to investigate

Inspect long-held connections and transaction lifetimes, check database capacity, and fix unnecessary connection retention before raising the pool limit.

Backlog growth

A queue is growing faster than it drains.

Issue type: Background job failure (Missed, duplicated, stuck or empty scheduled work.)

Job queue growing for 6 hours

Status: Open

Description

Incoming jobs are outpacing completions, steadily increasing the amount of accepted work waiting for processing.

What happened

The job queue grows for six consecutive hours because enqueue counts remain above completion counts. Older jobs continue aging even though workers are active. The service is processing some work, but its throughput is insufficient to meet the incoming load.

How to investigate

Compare arrival and completion rates by job type, identify slow or retried work, and restore enough processing capacity to drain the oldest backlog.

Missed schedule

A cron job didn't run, ran twice or ran long.

Issue type: Background job failure (Missed, duplicated, stuck or empty scheduled work.)

Nightly export skipped

Status: Open

Description

A scheduled export did not start, leaving downstream consumers without the fresh data normally produced by that run.

What happened

The nightly export has no start or completion record for Sunday, although neighboring scheduled runs are present. There is also no output for that scheduled interval. The gap is consistent with a missed trigger or admission failure rather than a job that ran and returned an error.

How to investigate

Check scheduler execution, timezone handling and overlap locks, then backfill the missing interval after confirming that replay will not duplicate exports.

Crash loops

Restarts, out-of-memory kills, failing health checks.

Issue type: Background job failure (Missed, duplicated, stuck or empty scheduled work.)

Worker restarting every 12 minutes

Status: Open

Description

A worker repeatedly restarts before it can sustain normal processing, interrupting in-flight jobs and delaying queued work.

What happened

The worker starts, processes jobs and exits on an approximately 12-minute cycle. Each restart loses the current process state and is followed by redelivery of unfinished work. The pattern indicates repeated process failure, but the exit reason must distinguish a crash from a resource kill or failed health check.

How to investigate

Inspect exit codes, memory use and health-check events around each restart. Correct the failure and verify that interrupted jobs resume without duplicate side effects.

Expiry ahead

Certificates, domains, API tokens, OAuth grants.

Issue type: Capacity risk (Heading for a limit before it bites.)

TLS certificate expiring

Status: Open

Description

A certificate in the active serving path is approaching expiry without evidence that a replacement has been installed.

What happened

The TLS certificate served by the endpoint expires in six days. Repeated checks still return the same certificate, so renewal has not yet reached the serving layer. Connections work now but will fail validation if that certificate remains active past its validity period.

How to investigate

Check renewal automation and certificate deployment, install the replacement, and verify the certificate actually served to clients.

Cloud provider errors

Throttling or errors from AWS or GCP APIs.

Issue type: Dependency failure (A vendor or upstream service is broken or has changed.)

S3 slowing uploads

Status: Open

Description

Object uploads are spending more time retrying storage-provider requests, slowing user transfers and tying up upload workers.

What happened

S3 requests return SlowDown responses during uploads, followed by repeated attempts for the same objects. The added duration sits in storage retries rather than local file processing. Successful final responses can conceal the extra wait and resource use along the upload path.

How to investigate

Review request concurrency and retry backoff, compare affected object prefixes, and confirm that throttled uploads resume safely without restarting completed work.

Third parties

Webhook gap

Expected inbound webhooks stop arriving.

Issue type: Dependency failure (A vendor or upstream service is broken or has changed.)

Email delivery webhooks stopped

Status: Open

Description

Email sends continue, but delivery callbacks have stopped, leaving local delivery status unable to reflect what the provider actually did.

What happened

No email delivery events arrive for an hour while outbound send requests still receive provider IDs. The gap is specific to callbacks rather than all email activity. Messages may have been delivered or failed without either outcome reaching the application.

How to investigate

Compare provider delivery records with local webhook receipts, check the callback endpoint and signature validation, then replay missing events safely.

Vendor degradation

Errors or latency from a provider you depend on.

Issue type: Dependency failure (A vendor or upstream service is broken or has changed.)

Sign-in codes never sent

Status: Open

Description

Sign-in requests appeared successful while the email provider rejected the messages needed for users to finish authenticating.

What happened

Sign-in codes never arrived because the email provider no longer considered the sending domain verified. The send ran as a background task, so the API still returned 200.

How to investigate

Restore sending-domain verification and inspect background send results. Surface rejected code delivery instead of treating the API’s 200 response as proof of delivery.

Vendor rate limiting

You are being throttled.

Issue type: Dependency failure (A vendor or upstream service is broken or has changed.)

Ticketing API quota ran out every day

Status: Open

Description

A recurring ticket crawl exceeded its provider quota and left the last region partially stale while continuing to report normal completion.

What happened

A daily crawl hit its ticketing API quota every day for two weeks, about 10.5k requests against a 10k limit. The last region was never fully refreshed, and the job ended normally each time.

How to investigate

Budget requests across regions, resume from the incomplete portion after quota recovery, and record partial completion whenever the crawl stops at the provider limit.

Contract change

A vendor's response shape changes.

Issue type: Dependency failure (A vendor or upstream service is broken or has changed.)

Vendor field arriving empty

Status: Open

Description

A provider response no longer supplies a field the application requires, interrupting processing even though the upstream request succeeds.

What happened

Previously populated values arrive empty in successful provider responses. The application still assumes the field is present and cannot complete the corresponding update. The change crosses the integration boundary without an HTTP failure, so transport-level monitoring remains healthy.

How to investigate

Compare raw response shapes with the expected contract and provider changes, validate required fields, and handle the missing value explicitly before retrying updates.

Vendor incident match

A provider's status page incident lines up with your errors.

Issue type: Dependency failure (A vendor or upstream service is broken or has changed.)

Login errors match a provider incident

Status: Open

Description

Sign-in failures coincide with an identity provider incident, suggesting an upstream dependency problem rather than a broad application outage.

What happened

Login errors begin in the same interval and region described on the identity provider’s status page. Failures occur during the provider exchange while unrelated application requests continue. The timing and affected dependency support the correlation, but do not exclude an additional local fault.

How to investigate

Compare failing exchanges with the provider’s incident scope, check local configuration, and monitor recovery while giving users a clear retry path.

LLM behavior drift

Model outputs change: length, refusals, malformed JSON, token use.

Issue type: Dependency failure (A vendor or upstream service is broken or has changed.)

Structured output failing 4% of the time

Status: Open

Description

Model responses are failing the structured-output contract more often, preventing downstream tasks from consuming otherwise successful completions.

What happened

Structured-output parse failures increase from 0.1% to 4% on the same feature. Invalid responses contain missing fields or text outside the expected JSON shape. Provider requests still complete, but the application cannot safely use those results and must reject or retry the affected tasks.

How to investigate

Compare model version, prompts and schema validation across the change, inspect invalid outputs, and verify a constrained-output fix before restoring normal processing.

Data integrity

Write without persistence

A save is acknowledged but never shows up later.

Issue type: Silent failure (A feature looks fine but does not work: no-op actions, swallowed exceptions, partial completion, wrong results, stuck states.)

CI sync saved nothing and reported success

Status: Open

Description

A CI sync reported success after fetching pipelines but storing none, allowing stale project data to look like a healthy refresh.

What happened

A CI sync ran its full 30 minutes, fetched thousands of pipelines, saved none of them and marked itself successful. Per-project errors were swallowed, so the sync history looked healthy while the data went stale.

How to investigate

Inspect the swallowed per-project errors, reconcile fetched pipelines with persisted rows, and rerun affected projects only after writes are verified.

Duplicate processing

The same event, job or payment handled twice.

Issue type: Data integrity (Lost writes, duplicates, corruption, mismatched records.)

Two welcome emails per signup

Status: Open

Description

Each new account receives two welcome emails because the same signup event can trigger delivery more than once.

What happened

Two completed send attempts share the same signup event ID and recipient, but use different delivery IDs. A retried event enters the welcome-email handler again without a recorded delivery guard. The duplicate side effect reaches the user even though both attempts are individually successful.

How to investigate

Trace event redelivery and the send guard, make delivery idempotent for each signup event, and verify that replay produces only one email.

Reconciliation mismatch

Counts disagree between systems.

Issue type: Data integrity (Lost writes, duplicates, corruption, mismatched records.)

Deposit paid out but never credited

Status: Open

Description

A deposit’s later payout did not update the user’s wallet after the provider had previously reported that deposit as failed.

What happened

A payment provider reported a deposit as failed, then paid it out 40 minutes later. The money arrived, but the user’s wallet was never credited, and nothing errored.

How to investigate

Compare the provider’s final deposit state with the wallet ledger. Reconcile the missing credit and verify that later state changes are handled without duplicate crediting.

Business metric drift

Signups, applications, payments or messages move far outside their usual range.

Issue type: Business flow breakage (A drop in a key metric with a technical cause.)

Applications down 35%

Status: Open

Description

Completed applications are below their usual level despite comparable entry traffic, pointing to a problem within the submission flow.

What happened

Applications are down 35% against the same hour last week, while visits to the application form remain comparable. The divergence begins between submit attempts and stored applications. That pattern suggests a processing or validation problem rather than a simple decline in demand.

How to investigate

Compare submission outcomes and validation reasons with the baseline period, then trace affected attempts through persistence before attributing the drop to user behavior.

Empty output

Jobs report success but produce nothing.

Issue type: Background job failure (Missed, duplicated, stuck or empty scheduled work.)

Retention scrub redacted nothing

Status: Open

Description

A retention cleanup job kept completing without redacting the prompt data it had identified for organizations that opted out of retention.

What happened

For organizations that opted out of prompt retention, a cleanup job kept finding data to scrub, redacted zero rows and moved on. It ran on schedule, without exceptions, for a month across 11 organizations.

How to investigate

Compare candidate selection with the redaction predicate and affected-row count. Verify that eligible data is removed before rerunning the affected cleanup.

Stale data

Caches and sync jobs stop refreshing.

Issue type: Data integrity (Lost writes, duplicates, corruption, mismatched records.)

Directory data three days stale

Status: Open

Description

Directory reads are serving an old snapshot even though the upstream source has changed, leaving users with outdated records.

What happened

The directory’s latest successful refresh is three days old. Reads continue returning that snapshot, while sync attempts fail to advance its freshness marker. Availability checks stay green because the cache still responds, but newly added or changed entries are absent.

How to investigate

Trace the refresh job and checkpoint update, compare source records with the cached snapshot, and verify freshness after a safe resync.

Cost

Log volume spike

A deploy suddenly gets very noisy.

Issue type: Cost anomaly (Spend spikes in logs, cloud or LLM usage.)

Debug line logging 40M times a day

Status: Open

Description

A newly frequent debug message is dominating the log stream, increasing ingestion and storage work without a corresponding rise in traffic.

What happened

One debug line accounts for 40 million log events per day after a deploy. Its call site sits inside a repeated operation, so each request now emits many copies. The volume change comes from logging behavior rather than a comparable increase in useful application activity.

How to investigate

Locate the repeated log call, reduce or sample redundant output, and confirm that diagnostic coverage remains useful after the volume returns to baseline.

Cloud spend anomaly

Spend jumps for a service or resource.

Issue type: Cost anomaly (Spend spikes in logs, cloud or LLM usage.)

Data transfer costs doubled

Status: Open

Description

Data-transfer spending doubled without comparable traffic growth, suggesting that requests are moving data through a more expensive path.

What happened

Transfer costs double overnight while application request counts remain similar. The increase is concentrated in traffic between services rather than user-facing response size. A routing or placement change may be causing repeated or cross-region transfer that ordinary request metrics do not expose.

How to investigate

Break transfer usage down by source, destination and deployment change, then verify whether routing or duplicated fetches explain the additional bytes.

LLM spend spike

Token usage jumps by feature or customer.

Issue type: Cost anomaly (Spend spikes in logs, cloud or LLM usage.)

Agent loop burned a week of budget

Status: Open

Description

An agent repeatedly issues similar model calls without completing its task, concentrating unusually high token usage in one workflow.

What happened

One account’s agent run consumes a week’s normal token budget in a day. Consecutive calls repeat the same tool result and carry growing context, but no terminal task outcome appears. The repeated loop increases cost without producing additional useful progress.

How to investigate

Inspect the repeated decision and tool result, stop the unproductive run, and add bounded retries and a no-progress exit before restarting the task.

Telemetry gaps

Service went quiet

A source stops sending logs.

Issue type: Observability gap (Places where you are blind, or telemetry that creates risk.)

Worker fleet went silent

Status: Open

Description

A worker fleet stopped emitting logs after a configuration change, removing the diagnostic trail needed to understand its ongoing work.

What happened

Worker log volume drops to zero while queue activity shows that jobs are still being processed. The silence begins with the configuration change and affects the fleet rather than one host. This points to the logging or delivery path, not proof that every worker has stopped.

How to investigate

Compare logger and exporter configuration with the previous version, inspect delivery errors, and verify a known worker event from emission through ingestion.

Unreadable format

A new log format can't be parsed.

Issue type: Observability gap (Places where you are blind, or telemetry that creates risk.)

New log format unreadable

Status: Open

Description

A logger upgrade changed record formatting, causing incoming logs to lose the structured fields used for analysis and correlation.

What happened

The source continues sending records, but parsing failures begin with the upgraded logger. Raw lines contain a new envelope around fields the parser expects at the top level. Events arrive without reliable severity, message or request context, reducing their diagnostic value.

How to investigate

Compare old and new raw records, update the parsing contract, and verify representative multiline and error events before considering the source healthy.

Blind spot

An important route or job has no telemetry.

Issue type: Observability gap (Places where you are blind, or telemetry that creates risk.)

Payments endpoint logs nothing

Status: Open

Description

A new payments endpoint handles requests without producing application telemetry, leaving failures and incomplete operations difficult to investigate.

What happened

Ingress records show requests reaching the endpoint, but no matching application start, outcome or request ID appears in the log stream. Other payment routes still emit those events. The missing coverage prevents a request from being followed through validation, provider calls and persistence.

How to investigate

Trace the route’s logging middleware, add structured outcome events with correlation IDs, and verify the trail without recording payment credentials or sensitive payloads.

Clock skew

Timestamps drift between sources.

Issue type: Observability gap (Places where you are blind, or telemetry that creates risk.)

Host 4 minutes behind

Status: Open

Description

One host timestamps events earlier than its peers, making a single request appear to execute out of order across services.

What happened

Events from the host are four minutes behind matching request IDs from other sources. Ingestion times remain close, so the discrepancy lies in the recorded event time rather than transport delay. The skew distorts timelines and can mislead latency or sequence analysis.

How to investigate

Check host time synchronization and timestamp serialization, correct the clock, and compare correlated events again before relying on cross-service timing.

Examples from the Sazabi Detection Catalog. Some signals are still on the way.

Works with your stack

Browse all integrations

Chat providers (3 integrations)

• Slack
• Microsoft Teams
• Discord

Git providers (2 integrations)

• GitHub
• Bitbucket

Issue trackers & on-call (6 integrations)

• Linear
• Atlassian
• PagerDuty
• incident.io
• Rootly
• VictorOps

Log sources (73 integrations)

• AWS
• Vercel
• Supabase
• Cloudflare
• OpenTelemetry
• Fluent Bit
• GitHub
• Linear
• Webhooks
• Cursor
• GitHub Copilot
• Factory Droid
• OpenHands
• OpenClaw
• Hermes Agent
• Claude Agent SDK
• Google Cloud
• Railway
• Render
• Fly.io
• Netlify
• DigitalOcean
• Porter
• Modal
• Northflank
• Neon
• Convex
• Inngest
• Trigger.dev
• Temporal
• Mastra
• LangChain
• E2B
• Daytona
• OpenRouter
• Datadog
• Sentry
• PostHog
• Prometheus
• Elastic Cloud
• SigNoz
• Vector
• Respan
• New Relic
• evlog
• Plain
• Shopify
• Okta
• Auth0
• WorkOS
• SentinelOne
• Palo Alto Networks
• Zscaler
• HashiCorp Vault
• Jamf Pro
• osquery
• Linux auditd
• Stripe
• Claude Code
• Codex
• Devin
• Doppler
• Gemini
• Grafana Alloy
• oh-my-pi
• Sazabi Browser SDK
• Tailscale
• Unkey
• Jenkins
• Buildkite
• RunsOn
• WarpBuild
• Sazabi React Native SDK

Infrastructure tools (17 integrations)

• AWS
• Google Cloud
• Vercel
• Cloudflare
• Kubernetes
• Terraform
• Railway
• Render
• Fly.io
• Netlify
• DigitalOcean
• Porter
• Argo CD
• Azure
• Heroku
• RunPod
• Tailscale

Database tools (12 integrations)

• Supabase
• Neon
• Postgres
• MySQL
• Redis
• ClickHouse
• Convex
• PlanetScale
• Airbyte
• Aiven
• MongoDB Atlas
• MongoDB Shell

AI & workflow tools (32 integrations)

• Codex
• Cursor
• Gemini
• OpenCode
• Temporal
• Inngest
• Claude Agent
• Warp Oz
• Capy
• Tembo
• Hoplite
• Replicas
• Composio
• Exa
• The Context Company
• RentAHuman
• Cekura
• Langfuse
• Braintrust
• Respan
• Tines
• DeepWiki
• Context.dev
• AgentCat
• CodeRabbit
• Dagster
• DBOS Cloud
• Deepsec
• Devin
• ElevenLabs
• LangSmith
• Rivet

Team & operations tools (43 integrations)

• Notion
• Google Drive
• Grafana
• Attio
• 1Password
• Intercom
• Axiom
• Honeycomb
• Better Stack
• Pydantic Logfire
• down.guide
• Pylon
• Clay
• Calendly
• Circleback
• Granola
• Happenstance
• Superhuman
• Mercury
• X
• Wiz
• Vanta
• Drata
• Semgrep
• Socket
• GitGuardian
• Google Security Operations
• VirusTotal
• Have I Been Pwned
• cve.now
• Clerk
• Resend
• Autumn
• Arize
• Checkly
• DoorDash
• Graphite
• GrowthBook
• Herd
• Mobbin
• Secureframe
• Stream
• Twilio

Case studies

Read case studies

Weave

How Weave Reclaims 20+ Engineering Hours a Week by Replacing Manual Detection With Sazabi

Sazabi turned what used to be blind spots into issues we catch and fix before customers ever notice. The next best thing to preventing a problem entirely is knowing about it right away, and that’s exactly what Sazabi gives us.

Andrew Churchill, Co-Founder and CTO at Weave

• 8.5 min: Time to root cause a production issue
• 9 min: Time to set up

Read the case study

Mastra

How Mastra Replaces 45-Minute Investigations With Root-Cause Alerts From Sazabi

Sazabi gave us the production visibility we needed for launch without building out our usual observability setup. Now it’s a safety net we trust every time we deploy.

Abhi Aiyer, Co-Founder and CTO at Mastra

• 45 min: Manual investigation time before Sazabi
• 150 issues: Production issues identified in two weeks

Read the case study

XMTP Labs

How XMTP Labs Cut Bug Detection From Days to Minutes With Sazabi

With Sazabi as part of our observability stack, we're so much faster at getting to root causes than we've been with any of our previous approaches.

Nick Molnar, CTO at XMTP Labs

• 5 min: Time to flag a major incident
• 20 min: Time to ship a fix for a critical issue

Read the case study

From our blog

• Introducing Sazabi Security: Security Monitoring That Investigates Before It Alerts: Sazabi Security watches your identity, cloud, and network logs for attacks, investigates anything suspicious, and opens a security issue only when something is actually wrong.
• Logs Are Now Free for YC Companies: The current YC batch gets 3 years of free logs (up to 1 PB) and 12 months of the Sazabi Startup plan. Alumni get 2 years and 6 months.
• Introducing Sazabi BYOC: Run Sazabi in Your Own Cloud: With Sazabi BYOC, the part of Sazabi that receives, processes, and stores your logs runs in your own cloud account, and Sazabi operates it.

View all articles

A different approach to observability and security

01 Everything’s a log

Metrics, traces, application events, agent actions. They all describe what happened. Logs give humans and agents one foundation for understanding a system.

02 Logs power anomaly detection

You shouldn’t have to predict every failure to catch it. A log foundation lets Sazabi discover changes in your system’s behavior and investigate what happened.

03 Built for an AI-native world

AI is changing how software is built and run. Sazabi gives humans and agents shared access to the evidence and tools they need to act.

What customers say

In our first two days, Sazabi caught ~8 issues we wouldn't have found otherwise, even with Sentry.

Bence R., Hoplite

Living in the future: Sazabi opens the PR, Cursor risk-assesses and approves it, CI is all green.

Evan, AGREE

Not every alert is high priority, but every one is actionable. I'm very impressed by the quality.

Yash N., Sandstone

Some of the issues Sazabi sends make me go 🤯, in a very helpful way. It matters more as our microservices grow.

Nanda G., Taiga

The Slack alerts are so good I haven't needed to open the dashboard. A coding agent fixes bugs as they come in.

Charlie L., Autumn

Sazabi is the backbone of our on-call. And with the new security alerts, we can freak out in real time.

Ed P., WAJO

Ready for enterprise

Bring your own cloud

Run log intake, processing and storage in your own AWS account. Sazabi operates the deployment.

• Storage your organization owns
• Your retention policy
• Access you can revoke

Read the BYOC announcement

Compliance

Security standards and privacy commitments to support your team’s review.

• SOC 2
• SOC 1
• ISO 27017
• ISO 27001
• GDPR

Visit the trust center

Access & security

Connect your identity provider and control access across your organization.

• SSO with SAML / OIDC
• SCIM provisioning
• Role-based permissions
• Restricted project access
• Two-factor authentication

Explore access controls

FAQ

What is Sazabi?

Sazabi is an AI-native observability and security platform for engineering teams and coding agents. It reads your production logs alongside your code, detects the issues that matter, investigates each one down to its root cause, and sends the result to the tools your team already uses.

Do I need to write monitors or alert rules?

No. Sazabi watches your logs for changes worth a closer look, such as an event that stops happening, a step that starts failing quietly, or latency that jumps after a deploy. Its agent investigates those signals, confirms there is real impact, and only then opens an issue, without monitors, thresholds or alert rules to maintain.

Which logs and tools does Sazabi connect to?

Send logs from sources like Datadog, PostHog, Sentry, Google Cloud, Supabase and Cloudflare, and connect your code from GitHub so Sazabi can trace issues back to the commit and file behind them. Issues reach your team in Slack, Microsoft Teams, email or SMS.

How does Sazabi work with coding agents?

Every issue comes with its root cause and a fix plan you can hand straight to a coding agent such as Claude Code, Codex or Cursor. Agents can also ask Sazabi about your logs through the CLI and MCP while they work.

Can my logs stay in my own cloud?

Yes. With Sazabi BYOC, log intake, processing and storage run in your own AWS account and your logs stay in storage your organization owns, while Sazabi operates the deployment. Query results and log excerpts can still reach Sazabi and model providers.

How much does Sazabi cost?

Hobby costs $50, Startup $200 and Growth $1,000 per 30-day cycle, each with included usage. Enterprise has custom pricing and terms. See the pricing page for what each plan includes.

How do I get started?

Run npx @sazabi/cli start in your terminal to set up Sazabi, or follow the quickstart in the docs.

Canonical URL

https://www.sazabi.com