Pull runbooks and postmortems from Notion into a Sazabi investigation

Last verified on Nov 8, 2026.

When something breaks at 2 a.m., the knowledge that helps is usually already written down: the runbook for the service, the postmortem from the last time the queue backed up, the page that says who owns the billing job. It lives in Notion, and you read it in a different tab from your logs. With Notion connected, the Sazabi agent can read that page while it searches your logs, then tell you what the runbook says about the exact error it just found.

What the Sazabi agent can do with Notion

There are two ways in, set up separately.

The MCP connector talks to Notion's hosted server at mcp.notion.com/mcp over OAuth. During authorization you pick the pages and databases to share, and the agent only sees those. The tools worth knowing:

• notion-search searches pages and databases by short keywords or a title, filtered by location (page, data source or teamspace). It returns up to 50 results with a path for each.
• notion-fetch opens one result. A very large page can come back with truncated set and a list of unknown_block_ids, and the agent can fetch a subtree by passing one of those IDs back.
• notion-list-page-backlinks lists pages that link to or mention a page, which helps find every document that refers to a runbook.
• notion-query-data-sources reads rows from a database, such as an incident table. SQL queries over data sources need a Business or Enterprise plan with Notion AI.
• notion-get-self and notion-get-tool-access report who is connected and which tools and options your connection can use.

Write tools exist too, for example notion-create-comment. Sazabi gates them with the connection's read-only toggle and your organization's tool policy.

The ntn CLI runs in the agent's sandbox with a NOTION_TOKEN. The Notion docs show it making authenticated API requests from the terminal, as in ntn api v1/users. The integration behind the token must be connected to each page or database the agent needs.

Questions it answers

• What does our runbook say to do when this queue backs up?
• Did a past postmortem describe this same error, and what fixed it?
• Which page names the owning team for this service?
• What changed in the incident database in the past week?
• Which other pages link to this runbook, so I know what might be out of date?

A worked example: the runbook for an error the logs just surfaced

Your logs show repeated ledger-sync timeouts. You ask in the thread:

Find the ledger-sync runbook in Notion. Read it and tell me which step covers
upstream timeouts. Then list pages that link to it, and check the incident
database for rows that mention ledger-sync.

The agent calls notion-search with the keywords "ledger-sync runbook" and opens the best match with notion-fetch. If the page is long enough that part of it was skipped, it fetches the omitted subtree. It then calls notion-list-page-backlinks with that page's ID, which returns titles and URLs and no page content, and fetches the interesting ones. For the incident table it uses notion-query-data-sources where your plan allows it.

Notion's own search reference suggests fetching important matches before relying on them, and that applies here: a runbook can be stale. Treat what the agent reads as a lead, and ask it to quote the exact step so you can judge for yourself, and check the page's edit history. If the postmortem rows describe the same timeout and a fix, you have a candidate remedy to check against your current logs before you try it.

How it fits with other integrations

Documentation is one more input to the same thread. GitHub gives the agent the code behind an error, Linear records the work that follows, and Granola covers meeting notes if your decisions live there instead. The integrations index lists the rest, and pricing lists the plans.