Use X with Sazabi: check public reports against your own logs

Last verified on Nov 8, 2026.

Some outages are reported on X before anyone files a ticket. A payment provider degrades, a CDN has a bad hour, or your own users start asking whether the app is down. The posts carry timestamps, and those timestamps are useful evidence when you are working out when a problem started and whether it is yours.

Sazabi is AI-native observability and security. Connect X and the Sazabi agent can search public posts from the same thread where it is reading your logs.

What the Sazabi agent can do with X

There are two methods, listed on the X integration page.

The MCP connector points at X's hosted MCP server at https://api.x.com/mcp. Because X has no dynamic client registration for it, you paste in your developer app's app-only Bearer Token and Sazabi sends it in the Authorization header. X's own docs list the server's categories as posts, search, users, bookmarks, news and trends, and Articles. In app-only mode the agent gets the read side that needs no user context, as the Sazabi docs describe:

• Search X posts and retrieve real-time data.
• Look up users, posts and engagement metadata.
• Browse user timelines, mentions and trends.

It cannot post or act as a user. Bookmarks and Articles need user context, so they fall outside this mode.

The sandbox CLI gives the agent xurl, X's curl-like command-line tool, authenticated with four OAuth 1.0a values from your app. xurl takes raw paths such as /2/tweets/search/recent and has shortcuts like xurl search and xurl user. Use it when you want the agent to chain a search with other commands in the sandbox.

Questions it answers

• Are other people reporting problems with this provider right now?
• When did the first public report appear, compared with our first error?
• What are users saying to our support account in the last few hours?
• Does an outage on a third-party service match what we see in our logs?
• Which links or hashtags are spreading around the incident?

A worked example: is it us or the payment provider?

Checkout errors are rising. In a thread you ask:

Search recent X posts for "examplepay" with outage OR down OR failing,
excluding retweets, English only. Also look at posts replying to
@examplepaystatus. Tell me when the first matching post appeared, then
compare that with the first checkout error in our logs.

X's recent search takes operators, so the agent can build a query like examplepay (outage OR down OR failing) -is:retweet lang:en, and use to:examplepaystatus for replies. Recent search covers the last 7 days and returns up to 100 posts per request, so a busy incident can fill more than one page, and one page can't establish when reports began. Narrow the query to the incident window, and if a page comes back full, ask the agent for the next page before it calls any post the first report. It then orders the posts by time, takes the earliest relevant one and searches your logs for the first checkout failure.

The answer is a timeline with two sources on it. If public reports start after your first errors, the problem may be yours. If they start before, a provider issue becomes a stronger lead. Posts are weak evidence, since some are jokes or about something else, so treat this as a lead that your logs must confirm.

What access you get

Search depth follows your X plan. X documents full-archive search as limited to pay-per-use and Enterprise customers, while recent search is available to all developers. The sandbox CLI credentials include a user access token, and xurl can create posts, so scope that app's permissions to what you are comfortable having available to the agent.

How it fits with other integrations

Public reports are a hint, and your own telemetry is the proof. Send that through OpenTelemetry, and add the cloud view from AWS or Cloudflare. The observability tools category covers more sources. See the full integrations list, and pricing for Sazabi plans.