Console - Flashduty Docs

Public beta: AI SRE is now open to all accounts — no application needed. Sign in to the console and start using it; it’s free during the public beta. Features and the UI may continue to evolve.

Overview

A session is one complete conversation between you and AI SRE. It holds every message you send, the agent’s streaming replies, tool calls made along the way, and any artifacts the agent produces (such as code, reports, charts, or Skill archives). Each session is fully independent, with its own context, bound team, and environment. You switch between sessions in the left sidebar, and exchange messages, read replies, and view artifacts in the central chat area.

Sessions are isolated from one another: context, bound team, and environment do not affect each other. Switching sessions does not interrupt a turn that is already running — AI SRE keeps writing progress to the session, so when you return you can still see the streaming output.

Creating and Managing Sessions

The left sidebar is the single entry point for sessions. Click New Chat to start a fresh session. The list is sorted by most recent activity in descending order; only the most recent entries are shown initially, and older history is revealed incrementally with Show more. In a blank AI SRE session, four scenario suggestion cards appear above the composer: Investigate an incident, Query data with natural language, Reduce alert noise, and Schedule an automated inspection. Selecting a card only fills the composer; it does not send the prompt. You can edit it before pressing Enter.

Search and Filter

Search chats

The search box at the top filters sessions by name. When there are no results, it displays No matching chats found.

Filter by scope / status / activity

Click the Filter icon in the upper-right corner of the list to open the filter panel and combine the dimensions below. When any non-default filter is active, a small dot appears on the filter button as a reminder.

Dimensions available in the filter panel:

Dimension	Options	Notes
Scope	All / Personal / Team	After selecting Team, switch between My teams / Selected teams (default: My teams); only Selected teams expands the inline list where you can search and multi-select teams you belong to
Status	Active / Archived / All	Defaults to showing only Active sessions; switch to Archived to view archived sessions
Recent activity	All / 24 hours / 7 days / 30 days	Narrows results by the session’s most recent activity time

The panel footer provides Reset (restore default filters) and Done (close the panel).

Session Visibility and Permissions

The account is the hard access boundary for sessions: sessions are never accessible across accounts. Within the same account, personal sessions and team sessions use different rules for reading, continuing, and managing the conversation:

Session type	Can read / continue the conversation	Can rename, archive, delete, or attach an incident
Personal session (no team bound)	Only the creator	Only the creator
Team session (team bound)	Members in the same account who have the session ID	Session creator, account owner / admin, or members of the bound team

Pinning is a personal preference and does not modify the session itself; if you can read a session, you can pin or unpin it for yourself. Account owners and admins can manage team sessions, but they cannot read or manage another member’s personal session. The chat page header provides share controls, shown only when you have manage permission on the current session. Click the Copy share link button to enable sharing and copy the link to your clipboard (a “Share link copied” toast appears). The link appends a share_token to the current session URL, with the token in the URL fragment (after #). The share link is stable: while sharing stays enabled, copying it again yields the same link.

Topic	Details
Who can share	Members with manage permission on the session — the creator of a personal session, or the creator / account owner / admin / team members of a team session
Who can open it	Members who hold the link and are signed in to the same account; the link does not work across accounts or for anonymous visitors
What link holders see	The session opens in read-only mode with a “This is a read-only shared session” notice: they can inspect the full context (messages, tool calls, artifacts), and can also open a Subagent dispatch chip to view the child session’s execution details (also read-only); but the composer is replaced by the notice — they cannot continue the conversation or modify the original session
How to keep working	Link holders can click Fork into a new session to derive their own session and continue from there
How to revoke	Once sharing is enabled, a Remove share button appears in the header; clicking it invalidates the link immediately (a “Share removed” toast appears). Re-enabling sharing later generates a new link — the old link is not restored

Sharing mainly changes the visibility of personal sessions: a team session is already readable by any member of the same account who has the session ID (see the table above), whereas a personal session is visible only to its creator by default — a share link is the only way for other members of the account to open it.

Incognito sessions cannot be shared.Subagent / A2A child sessions can’t have sharing enabled on their own either — sharing can only be enabled on the root session. But once you share the root session, link holders can open a Subagent dispatch chip in the read-only view and view the corresponding child session’s execution details, also read-only; child sessions are view-only and don’t offer Fork into a new session. Revoking the root session’s share also invalidates access to its child sessions.

Per-Session Actions

Hover over a session row to reveal the pin and archive actions. A pinned session displays a persistent pin icon to the left of its name.

Action	Entry point	Notes
Pin / Unpin	Inline pin button on hover	Pinned sessions appear at the top of the list
Archive / Unarchive	Inline archive button on hover	Archived sessions are hidden from the active list by default; switch to Archived in the filter to find them
Rename	Click the chat title to edit in place	Press Enter or click away to confirm; press Esc to cancel; maximum 60 characters
Delete	Delete button in the chat header (requires manage permission)	Deletes the session after confirmation; the conversation history cannot be recovered. Deletion also best-effort stops the session’s still-running background command / monitor processes — a failed stop does not block the deletion, and no task notifications are sent for it

A new session does not need a manual title: after the first turn completes, the system auto-generates a title server-side from the session’s content and pushes it back through the session stream as a session.renamed frame, which updates the sidebar and title in place. Until that finishes, a placeholder title derived from your first message is shown so the sidebar never sticks at “Untitled.” You can rename the session at any time to override the auto-generated title (title limit: 60 characters).

Hovering over a session row for a moment shows a tooltip with the full session name, the associated team, and the exact timestamp — useful when the name is truncated and you need to confirm you have the right session.

List Status Indicators

Each row shows status indicators by priority: while a session is running, only the spinner is shown; otherwise the background-task badge and the unread dot can appear together; when neither applies, the relative time is shown.

Indicator	Meaning
Spinning circle	The agent in this session is running (a turn is in progress or waiting on subtask reports); takes priority over all other indicators
🔭 + count	The session has that many live background tasks (monitors / background commands) — see “Task Panel and Background Tasks” below
Blue dot (unread)	The agent has produced new content you have not yet viewed; can appear alongside the 🔭 badge
Relative time	When none of the above applies, the relative time of the last activity is shown (e.g. `5m`, `3h`, `3d`)

Opening a session clears its unread dot.

Sending Messages and Streaming Responses

Type a message in the input box at the bottom and press Enter to send. The input box supports Markdown and slash commands (type / to open the command menu) to trigger built-in skills and commands. When the console publishes a new version, a version update notice appears above the input box: “A new version of the console has been published. Refresh the page to continue.” Click Refresh to reload the page and use the new version; clicking the close button hides the notice, and it will not repeat for the same version (the notice only appears in the full web console, not in embedded mode or on-premises deployments).

Attachments and Context References

Upload attachments

Click the plus button at the lower left of the input box to choose files, or paste images directly. Supported formats include images, PDFs, text / Markdown / CSV / HTML, and Office documents (Word / Excel / PowerPoint), up to 20 MB per file. HTML files are read as plain text and rendered in the sandbox — any scripts inside them are not executed. A single message can carry at most 9 attachments, and the total size of all attachments in one message cannot exceed 50 MB; both limits are validated client-side as soon as you pick the files, and exceeding either shows a corresponding message — at this point the attachments are only staged locally (pending chips) and uploaded together when the message is sent. Screenshots can be pasted directly into the chat.Extensions not listed above — such as code and config files like .go, .py, .yaml — are also accepted as plain text, as long as the entire file content is valid UTF-8. Empty files are the exception and are still rejected.Besides individual files, you can upload a whole folder: choose Upload folder from the plus menu to pick a local folder, or drag a folder straight into the input area. Folders are handled as follows:

File count limit: a single folder may contain at most 50 files; a folder over the limit is rejected outright (“This folder exceeds the 50-file limit; please choose a smaller folder”) instead of keeping only the first 50. node_modules directories and files / directories starting with . are silently ignored and don’t count toward the limit.
Per-file validation: every file in the folder is still checked against the single-file rules (20 MB per file, 50 MB total, type validation). Files that fail are skipped, and after you pick a folder the input area shows a “Skipped N files” list naming each file and its skip reason (over 20 MB / over the 50 MB attachment total / not a text file / unsupported file type).
Attachment counting: the whole folder counts as 1 attachment in a message, toward the same 9-attachment limit.
Directory structure preserved: the relative path of every file in the folder (including the top-level folder name) is preserved and staged into the sandbox. The agent sees a path-sorted file listing (an envelope with the file count and total size) rather than the file contents inlined into context; it reads individual files on demand with the read / bash / grep tools inside the sandbox.

Inline truncation of large files: attachments reach the agent as extracted text. When the extracted text exceeds 64 KB, only the first 32 KB is inlined (cut at a valid UTF-8 boundary), and the attachment envelope carries a pointer to the full file staged in the sandbox (like ~/.flashduty/attachments/...) — if the full content matters, ask the agent to read the file from the sandbox with the read / bash tools; nothing is lost. In addition, PDFs larger than 3 MB are no longer passed natively to the model; they fall back to text extraction under the same truncation rule.

Context references

When you enter AI SRE from an incident, alert, monitor rule, or monitor target page, the related object is embedded into the input box as a reference capsule — a small inline tag indicating the kind of object referenced — an incident, alert event, alert, monitor rule, host, monitor target, or on-call analytics — that travels with the message so the agent can start its analysis from that object directly. Click the capsule to open the referenced object in a new tab, or click its close button to remove the reference before sending. A single message can carry multiple references. Besides objects carried in automatically from a related page, you can also type @ directly in any session’s input box to trigger an incident search dropdown (supporting fuzzy keyword search and a list of recent incidents); selecting one inserts the same kind of reference capsule — a standalone entry point available at any time. Typing an email address does not false-trigger it: when the @ directly follows an email-address character (a letter, a digit, or one of ._%+-), the picker does not open; an @ after a space or adjacent to Chinese text still triggers it.

Knowledge and skills

When a session starts, the knowledge packs and skills for the bound team are loaded automatically. See Knowledges and Skills for details.

Real-Time Streaming Output

After you send a message, the agent’s reply is streamed back in real time — text appears as it is generated, and tool calls and reasoning steps are rendered as they occur. The moment you send, the frontend optimistically marks the turn as “running”; the backend’s running status takes over after roughly 300 ms, so the running state is not lost even if you navigate away and return.

While a turn is running, the Send button changes to a Stop button. Clicking Stop immediately interrupts the current turn: the UI reflects this right away, and the interrupted turn is labeled “Interrupted” and remains visible after a page refresh.

Queueing Messages While Running

The input box remains active while a turn is running: you can keep typing and send messages, which are queued and executed in order after the current turn completes. Queued messages appear in a collapsible card above the input box, with a header showing the queue count (e.g. “3 queued”); each queued message can be edited or removed individually, and when more than one message is queued, the card also offers a Clear all action in its top-right corner. The queue is authoritative server-side: messages you have sent but the agent (actor) has not read yet live in the server-side session queue, projected by the pending_messages field of the POST /safari/session/get response (in execution order). Before the agent starts processing one, you can withdraw it — the endpoint is POST /safari/session/message/cancel, whose request body carries session_id and invocation_id (the call ID the 202 ack / user_message_enqueued frame handed you when the message was sent); the response’s result field tells you what happened:

Result	Meaning
`removed`	The message was removed from the queue and will never be executed; the server pushes a `user_message_cancelled` frame to every subscriber, and clients drop the corresponding pending bubble
`consumed`	The actor had already read the message — it belongs to the running turn; the withdrawal does not take effect and that turn still executes (“too late”)
`forbidden`	Only the message’s author may withdraw it; a call by anyone else returns `ErrAccessDenied`

Withdrawal only touches the waiting queue: an envelope the actor has already read can no longer be withdrawn (it returns consumed) — to interrupt a turn that is actually executing, use Stop. Only plain human messages can be withdrawn — question answers (function_response) and internal-producer envelopes (automation, child-session notifications, parent initial messages) are not included. The capability also applies to queued messages sent through API integration. The caller needs participate permission on the session (the same gate as sending a message or interrupting), and only the message’s author can actually withdraw it — both conditions must hold for the result to be removed.

Environment Initialization

The first time a session runs, an environment initialization card appears in the chat stream and steps through how the runtime environment (the sandbox) becomes ready: set up a cloud container → start the runtime; if the cloud template carries a setup script, init and reclaim runs add a third phase, run the setup script (resuming an existing sandbox never reruns it). The phases run serially, showing only the step currently in progress; once everything is done, the card collapses into a single result line that reflects whether this run created, resumed, or rebuilt the sandbox:

Mode	Collapsed label	Meaning
Init	Initialized session	A brand-new cloud container was created for the session
Resume	Resumed session	The previous sandbox was reused, with its files intact
Reclaim	Rebuilt session	The previous sandbox had been reclaimed, so a new container was created

Sessions bound to a self-hosted BYOC Runner skip the cloud phases: the init card shows a single phase — Connecting to the self-hosted runner (for init, resume, and reclaim alike) — which becomes Connected to the self-hosted runner once it succeeds, then collapses into the same result line. If connecting to the self-hosted runner fails, the card shrinks to a single-line error notice (Failed to connect to the self-hosted runner, with the specific reason) and offers no cloud phase-history expansion.

When the previous sandbox was reclaimed after being idle, the card warns: Previous sandbox was reclaimed after N min idle — saved files were reset. This means anything previously written to the sandbox filesystem is gone. Persist long-lived outputs by saving them as an Artifact or to a Knowledge Pack, rather than relying on transient sandbox files.

If an error occurs during initialization, the card switches to a Session setup failed error state; click it to expand the phase history and the specific error details. You typically need to retry with a new session, or contact Flashduty support.

Tool Calls and Artifacts

Tools the agent invokes during a turn (reading and writing files, querying monitors, executing commands, calling MCP tools, etc.) are rendered inline in the conversation as collapsible blocks. Click one to expand and inspect its inputs and outputs; they are collapsed by default to keep the chat readable.

Todo List

For multi-step tasks, the agent places a clickable progress badge in the chat stream (shaped like “Step X / N,” with a ring progress indicator); clicking it expands into a task plan list, with each step carrying a status icon (Pending / In progress / Completed / Cancelled) and a priority tag (High / Medium / Low). If the agent ends its turn while a step is still “In progress,” that step is shown as “Paused,” signaling that you need to send a new message before it can proceed — it is not still running in the background. The task plan is maintained only on surfaces that actually have someone watching it: write_todos (the built-in tool that maintains the list) is available only in console (web) and IM sessions — the web panel renders the TodoList card, and the IM side renders it as a progress card. Automation (automation) and API (api) sessions do not get the tool: the agent cannot call write_todos there and receives no “keep your todo list current” nudge, so multi-step work runs directly without producing a progress list (an automation run can still be opened in the console to see the full messages and tool calls, but there is no checklist). Dispatched child sessions (Subagent / A2A) are excluded as well — todo state is per-session, and a child writing todos would clobber the parent’s list. A list is only created when the task genuinely is multi-step: three or more distinct steps (previously judged as “2+ tool calls,” now tightened). Single-step lookups and pure conversation with no investigation behind it produce no list. Session entry kinds are described under “Session entry kind” above.

Agent Questions

While troubleshooting, the agent may need you to clarify something, in which case it inserts an interactive question card into the chat stream: single-select (picking an option automatically advances to the next question), multi-select (after checking options you must click Confirm / Next to proceed), or free-text input (press Enter to submit). The ✕ button in the top-right corner of the card skips the whole question (not shown for required questions); a multi-question batch also shows a “Question i of N” pager, which you can navigate with the ←→ keys or by clicking, and returning to an already-answered question preserves your previous selection. Keyboard shortcuts: ↑↓ to move between options, Enter to confirm, Esc to skip. A parked question is auto-skipped by a new message: when the model is parked on a question card waiting for your answer, sending a new message marks the parked question as skipped — the server writes a function_response (reason=user_replied_with_message, one entry per question in a batch) without driving the model; your new message runs immediately as the next turn, and the model in that turn sees “question skipped + what you said” instead of being blocked by the parked question. Conversely, a late answer never resumes that question branch: submitting an answer to a question that already has a user-side response (auto-skipped, or answered from another device) converts the answer into a plain message (rendered as the answer text — e.g. “(skipped)”) that joins the next turn — the same question is never resumed twice.

When Authorization Is Required

When a tool or MCP call is blocked because it lacks credentials or has not completed OAuth authorization, an “Authorize [resource name] to continue” card appears inline in the chat stream, in one of two forms:

Secret-based: clicking the card’s button opens an input field; paste your API key / token and save it, and the task resumes automatically. If a help link is configured, the card also shows “How do I get a key?”
OAuth-based: click Authorize to complete third-party authorization in the popup window. Once authorized, the card’s button changes to Continue task — you must click it manually to actually resume the blocked tool call.

OAuth authorization links expire. After expiry, the card shows “Authorization link expired, please retrigger the task” — you need to start a new task to get a fresh authorization link.

Subagents

When the agent delegates a subtask, a clickable dispatch reference line appears in the conversation: a status ring, a type badge (Agent / A2A), the subtask’s name and current intent, and right-aligned status and elapsed time; once finished it adds the tool-call count / token usage / total duration, and on failure a red reason line appears underneath. The reference line is a compact single row and carries no stop button — stopping lives in the task panel’s detail header (see “Task Panel and Background Tasks” below). Clicking the line opens a subagent session panel on the right, side by side with the main conversation — the main chat area shrinks accordingly rather than being covered by a modal. The panel can be expanded to fill the main area, or collapsed back to the side-by-side layout. Besides running, completed, failed, and interrupted, a subtask can also sit in one of two “needs you” states:

Awaiting authorization: an action area unfolds beneath the reference line — click Authorize to open the OAuth popup; once authorization completes, the button becomes Continue task, and clicking it lets the main agent resume the same task in place instead of starting a new one.
Awaiting input: the subtask has asked you a question and is parked waiting for an answer; the question text is read on the task’s row in the task panel, not inline on the reference line.

An orphaned subtask (its executor is gone) renders as Failed; a task terminated by the platform shows as Killed.

Task Panel and Background Tasks

Beyond subagents, the agent can push time-consuming work into the background. Tasks dispatched within a session come in three kinds:

Kind	Dispatched by	Notes
agent	Subagent / A2A subagent dispatch	Has its own child session — see “Subagents” above
shell	The `bash` tool with `run_in_background`	A long one-shot command (build, batch job, data pull); only its completion needs reporting
monitor	The `monitor` tool	A standing watcher task: watches a condition until it hits or reaches its deadline, and the script’s output flows back to the agent as event batches; a one-shot delayed action (e.g. “check again in half an hour”) is done with a monitor plus `sleep`

A unified Tasks panel on the right side of the session tracks every task of the session, grouped into Needs you / Running / Finished. There are three entry points:

The tasks button in the chat header: carries a count badge for “needs you + running” tasks, capped at 9+; the badge is red when any task needs you (awaiting authorization / awaiting input), and blue when tasks are only running.
The generation status row while a turn is running: shows the live task count (e.g. “3 tasks · 1 agent needs you”); clicking it opens the same task panel.
The tool row that started a monitor / background bash: the tool row in the conversation that started a monitor or a background command (bash with run_in_background) — when it is the only tool in its group, that group’s header — is itself that task’s handle in the transcript: its trailing external-link icon marks it clickable, the tooltip reads Open task detail, and clicking it opens that task’s detail panel directly. Such rows no longer expand into raw Input/Output (a background bash row used to show only the command, with no status or output). In a read-only shared session the detail opens in read-only mode as well.

Task details differ by kind: clicking an agent task opens the child session’s execution transcript (see above); clicking a shell / monitor task opens its own event-timeline detail, which includes the status (a running task also shows how many seconds ago its last liveness probe landed — probing happens roughly every 30 seconds), run duration, event count, output bytes, the monitor’s deadline (standing tasks with no deadline show “Persistent”), the exit code, the full command, and the event timeline in order. The stop button lives in the detail header — Stop task for shell / monitor tasks and Stop Subagent for subagents — and interrupts only that task, without affecting the main session. How this surfaces in the conversation stream:

A tool line that starts a background command reads Started background command; when a turn mixes foreground and background commands, the collapsed tool group counts each category separately (e.g. Ran 1 command, started 1 background command).
Each time a monitor’s condition hits, a 🔭 system line is inlined into the conversation: the first line shows the monitor’s description plus a first-line summary of that output batch, and clicking it expands the full batch in place.
When a task ends, a terminal line appears with the end state and a result summary, plus the exit code and a note when the task envelope carries them.
The monitor tool line itself does not expand into input / output — clicking it opens the corresponding task’s detail panel, where the bookkeeping it returns (task ID, output file, deadline, and so on) is presented more completely.

Two status indicators related to background tasks:

The 🔭 badge on a session list row means the session has live background tasks (standing_tasks; the number is the count). When the session is running, the spinner takes priority.
A session’s “running” indicator reflects only agent turns and subagent tasks: standing monitors / background commands do not keep a session “running” — a session with only standing tasks alive shows as idle.

Artifacts Preview

Files the agent produces are available as artifacts with an inline preview. Click an artifact to open the preview panel on the right, which renders the content by type:

Type	Preview
Code (multiple languages)	Syntax highlighting + line numbers
Markdown	Rendered view by default; toggle to Source
HTML	Rendered view by default (iframe sandbox); toggle to Source
Image	Displayed directly; a retryable error message is shown if loading fails
PDF	Rendered in the browser’s built-in PDF viewer
Skill archive (`.skill`)	Left-side file tree + right-side content; the whole package can be downloaded, and you can Save Skill to your account with one click

The preview panel provides Copy, Download, and Close actions.

Report-type artifacts (such as operational insight reports) can be generated as HTML containing Mermaid diagrams and charts, viewable directly in the rendered view. For operational insight capabilities, see Operational Insight Reports.

All published artifacts can also be viewed and managed in one place on the Artifacts page in the left navigation (list, search, filter by personal / team scope, card / list view toggle, sort by created / modified time, rename, download, and delete) — see Artifacts.

Status Page Update Drafts

The agent can call the statuspage_draft tool to draft an announcement for your public status page — a new incident or maintenance event, or an update appended to an existing event. Drafts are saved server-side and rendered in the conversation as a status page update draft card; but a draft is never published automatically: publishing a status page reaches subscribers immediately and cannot be recalled, so that step is always left to a human — review each item in the status page publish form in the console, then click publish.

What’s on the draft card

The card reuses the visuals, field order, and component status icons of the console’s corresponding cards (IncidentCard / MaintenanceCard), so what reviewers see is exactly what will be published:

Content	Description
Title	For a new event, the form’s `name` field (backend `title`, up to 255 characters); for an appended update, the title of the event it attaches to — the append-update form has no title field, so this serves as identification only (shows “Untitled status page update” when not provided)
Status / scheduled time	New maintenance shows “Scheduled for 〈start〉 → 〈end〉” (shows “No schedule set” when unset); otherwise the status text — incidents: Investigating / Identified / Monitoring / Resolved; appended maintenance updates: Scheduled / Ongoing / Completed
Body	The `message` field is fully rendered as Markdown — this is what customers will read; reviewers must see the whole picture, and it must not appear as plain text
Affected components	One chip per component: component status icon + name (hover shows “name · status”)
Target & type	Bottom left shows “Will publish to 〈status page〉” (appended updates show “Update · 〈event title〉”); the right side labels the type: Incident / Maintenance
Warning banner	If the draft message contains Markdown the status page editor doesn’t support and that would be silently dropped when loaded into the form (headings, code blocks, block quotes, images, strikethrough, inline code), the card lists each one in a warning banner — already detected by the tool at draft time

Card states

State	Behavior
Drafting	Skeleton screen, with “Drafting status page update…” at the bottom
Tool error	”Failed to generate draft” + the specific reason; you can ask the AI to try again, or create it manually on the status page
Incomplete draft	”Incomplete draft” + the same hint (the tool returned a result but no usable draft object)
Ready to review	Button is Review →: opens the corresponding status page form in the console in a new tab, with the draft content pre-filled (URL convention below)
Published	Button becomes a disabled Published; the bottom target becomes a link to the published change (`/status-page/{page_id}?menu=incidents\|maintenance&incident\|maintenance={change_id}`), so you can look back at what the draft eventually became
Draft expired / not found	Button becomes a disabled Draft expired, with “Draft expired or not found — ask the AI to draft a new one” — treated the same when the console query returns ResourceNotFound or a network error

Whether it has been published is a fact the card cannot observe on its own (publishing happens in the console, in another tab), so the card queries GET /status-page/draft/info?draft_id=... by draft ID, which returns status: pending | published. While the draft is still pending, it refreshes every time the window regains focus (“review here, publish there, come back” is the normal path); published and “draft not found” are both terminal states, and the result is cached for the lifetime of the current page. Read-only shared sessions don’t render the review button, and the draft status query is skipped as well.

Handoff URL for review

The draft itself lives server-side (fc-statuspage’s draft storage); only the draft_id crosses over to the console: the form pulls the body from /status-page/draft/info by ID. The URLs combine into four variants by “new / append” × “incident / maintenance”:

Scenario	URL
New incident	`/status-page/{page_id}?menu=incidents&incident=new&draft={draft_id}`
New maintenance	`/status-page/{page_id}?menu=maintenance&maintenance=new&draft={draft_id}`
Append incident update	`/status-page/{page_id}?menu=incidents&incident={change_id}&action=add-update&draft={draft_id}`
Append maintenance update	`/status-page/{page_id}?menu=maintenance&maintenance={change_id}&action=add-update&draft={draft_id}`

action=add-update makes the detail page auto-expand the append-update form; without it, the route only opens the event itself and the draft is never read. ?draft= carries only the draft ID — the draft is server-side state, not a chunk of JSON in the URL.

Tool specifics

Field	Description
`page_id` / `page_name`	Target status page (required) and its display name (used on the card)
`type`	`incident` (incident) / `maintenance` (maintenance)
`change_id`	Omitted = new event; set = append an update to that event. Before drafting, the tool first checks `fduty status-page list` and `fduty status-page change-active-list` — if the target already has an active event, it should append rather than open another one (a second event reads to customers as another separate outage)
`title` / `message`	Title for a new event (≤255 characters) and the body (required, Markdown; the status page editor keeps only bold, italic, links, bulleted / numbered lists, tables, and `---` dividers)
`status`	New incident: `investigating` / `identified` / `monitoring` / `resolved`; new maintenance: omit (whether it advances on schedule is decided by the publish form’s toggle); appended maintenance update: `scheduled` / `ongoing` / `completed`
`affected_components`	Affected components (`component_id` + `status`, optionally with display name `name`); incident component status: `operational` / `degraded` / `partial_outage` / `full_outage`, maintenance component status: `operational` / `under_maintenance`
`start_at_seconds` / `end_at_seconds`	Only for a new maintenance: planned window start and end, unix seconds (milliseconds and ISO strings are treated as invalid)

Channel differences: the console (web) and automation channels render the card above; IM and API channels don’t render cards — instead the agent puts a “[Review & publish](〈the same handoff URL〉)” link at the start of the reply, then summarizes the draft points in a sentence or two (IM message truncation doesn’t parse Markdown, so the link comes first to be safe). If saving the draft failed (no review_url), it falls back to a text summary and points you to the status page in the console to verify manually.

Message Actions

Hover over a message to reveal action buttons:

Action	Applies to	Notes
Copy	User message / artifact	Copies the message or file content to the clipboard
Retry	User message	Restarts a turn using that message
Edit	User message	Fills the message back into the input box for editing; if a turn is currently running it is interrupted first, attachments cannot be added while editing, and the Send button label changes to Send rewind
Fork	Agent reply from a completed turn	Creates a new session from the completed turn that produced that reply, so you can continue down a different investigation path

Editing a historical message is, under the hood, a rewind operation: once submitted, the conversation regenerates from that message onward, and any content after that message is replaced. Confirm before submitting. If the turn that produced the target message is still running or stopping, the rewind is rejected (rewind target invocation is still active) — wait for that turn to settle before submitting. When a rewind takes effect, the background processes and dispatched subagents spawned by the wiped turns are stopped along with it, and their task rows are removed from the task panel.

Forking a session

After a turn has fully completed, a Fork button appears beside the agent reply. Click it to open the Fork new conversation dialog. It pre-fills the source session’s scope and environment as suggestions, but every fork requires an explicit target scope and environment. Choose Personal or an accessible team, then choose Auto, a cloud Sandbox, or an online BYOC Runner. Click Confirm to create — and automatically open — a new session forked from the completed turn that produced that reply. Forking is useful when you want to try another path from the same investigation context. The new session keeps the conversation and tool-call history up to the selected turn, but it never inherits the source environment binding on the server. Available environments are filtered by the target scope. If you are not a member of the source team, the dialog changes to Personal; if the source environment is deleted, offline, never connected, or outside the target scope, it changes to Auto. Later turns from the source session are not included. The forked session includes a “Forked from conversation” divider; click it to return to the source position in the original session.

You can fork only from a completed turn in a top-level session. If the source session is still running, the selected turn has not settled, or the target is a Subagent child session, AI SRE rejects the fork.

If the forked portion of the conversation dispatched any Subagent or A2A tasks, those dispatch chips are copied over to the new session along with their respective child sessions — opening one still shows the execution details, and it never points at an original task you don’t have access to. Dispatches that had already completed or failed in the source session keep their real status (completed / failed), copied together with their result; only dispatches still in progress at fork time show as “Interrupted” — the new session has no executor picking them up, so they cannot continue running. If you need to rerun one, just start a fresh dispatch in the new session. Forking clears temporary state that only belongs to an in-progress run, such as active-turn caches, pending mount state, frontend state that has not been persisted, and current-turn counters. Persisted history, tool calls, and reusable compaction state are retained; team and environment binding are written to the new session based on your choice in the fork dialog. The forked session has its own context, so later messages, compaction, and run results do not write back to the source session.

Session Feedback

The chat header has a pair of session-level feedback buttons, Helpful / Not helpful (thumbs up / down), for rating the quality of the whole session. Clicking Not helpful opens a feedback card where you can select preset reasons and add a note:

Preset reason	Meaning
Wrong diagnosis / root cause	The diagnosis or identified root cause is incorrect
Didn’t find the root cause	The real root cause was never located
Remediation unavailable	The suggested remediation cannot be applied
Off-topic	The reply drifted away from your question

The card also has a free-text box to add specifics (optional). On submit, the feedback is persisted via POST /safari/feedback/create; when you reopen the session, the earlier rating is automatically refilled onto the header buttons.

Context Compaction

As a conversation grows longer, the session context approaches the model’s context-window limit. AI SRE automatically compacts older conversation history — summarizing it into a digest while preserving recent content — to free up context space without losing critical information. Every compaction boundary summary also appends a deterministic folded-resources manifest: it lists the resources folded out of context this round and how to get them back — skills re-read via skill(name), MCP server tool definitions re-discovered via tool_search, and A2A agent usage notes re-delivered automatically on the next dispatch or message. Post-compaction turns can recover those definitions on demand without keeping them in context. Compaction is triggered in four ways:

Trigger	Timing
Automatic (before a turn)	Before a turn starts, when context usage exceeds the threshold
Automatic (mid-turn)	During a turn, if context continues to grow and crosses the threshold again
Automatic (event count)	Once the conversation reaches about 500 events, even if token usage is still below the threshold
Manual	You explicitly trigger compaction with the `/compact` command

The event-count trigger is a safety net: in a session made of many short turns, the token estimate can stay below the threshold for a long time while the number of events (messages, tool calls, and so on) keeps growing. Compaction fires once the count reaches about 500, so the history window cannot freeze against the model’s per-load row cap. If you see compaction happen while the Context percentage is well below the threshold, this is why.

What You Will See

Compaction in progress: A status line reading “Compacting conversation context…” appears in the chat stream, showing elapsed time and progress; it disappears automatically when compaction finishes.
Compaction complete: The conversation remains coherent with no action needed from you. The most direct indicator is the Context usage percentage in the chat header dropping — it reflects the current utilization of the context window, and hovering over it shows exact token usage.
No compaction needed: When compaction is unnecessary (for example, the conversation history is too short, or it is already in a compacted state), a manual trigger returns an appropriate message such as “Context does not need compaction” or “Conversation history is too short to compact.”

Compaction is transparent to you: what you perceive is a continuous conversation. The agent retains a summary of the compacted content in the background, so subsequent turns can still build on earlier key conclusions.

Choosing a Runtime Environment

When creating a session, the input area has a separate environment selector alongside the team selector, which determines where the agent’s tool, Skill, and MCP calls actually execute. The selector has three sections:

Option	Description
Auto (default)	The backend automatically picks an available environment; falls back to the cloud sandbox if none is available
Cloud environment	Uses a Flashduty-managed cloud sandbox (the default template, or a cloud environment template already created for the account / team)
A specific BYOC runner	Pick one of the online self-hosted runners in your account, so the investigation reaches your private network

Self-hosted runners are shown by their current status: runners that are offline or have never connected appear dimmed in the list and cannot be selected; if a selected runner goes offline afterward, sending messages is also blocked with a corresponding notice. The environment choice is fixed once the first message is sent and the session is created. To switch afterward, see the in-place switching capability for IM sessions under “Session entry kind” below, or fork a new session.

Binding a Team

When you create a session you can bind a team to it. Once bound, the session automatically loads that team’s knowledge packs, skills, and MCP servers at startup, giving the agent the team’s domain context and capabilities from the very beginning. When no team is bound, the session runs in account scope.

Select a team

Use the team selector in the new-session input area to choose the team to bind. Your last selection is remembered, so you do not have to repeat it each time.

Automatic team context loading

As soon as the session starts, the knowledge / skill / MCP metadata for “account scope + bound team” is loaded and the agent is ready to use.

On-demand cross-team knowledge mounting

When the agent needs knowledge from another team, it reads that team’s knowledge directory on demand and mounts that team’s knowledge and capabilities as persistent context in the current session — a mount remains active for the lifetime of the session.

The bound team stays with the session: reopening the same session restores the original team binding, and the session’s team is also shown in the sidebar tooltip.

Automatic linking between incidents / war rooms and teams is still evolving. You can currently bind a team to a session explicitly; automatic binding in incident scenarios will continue to improve in future updates.

For the rules governing team scope for resources (account scope vs. team scope, visibility, and edit permissions), see the “Scope” section on each resource page.

Session entry kind

Every session is created with an entry kind (entry_kind) that identifies which surface produced it. The value is persisted to the database and returned in the create response.

Value	Source	Notes
`web`	Console	Default; unknown or missing values are automatically normalized to `web`
`im`	IM platform (Feishu / DingTalk / WeCom / Slack)	Set automatically by the IM path; enables in-place switching for the session (see below)
`api`	External API call	For programmatic integration scenarios
`automation`	Automated workflow	Sessions triggered by automation tasks

When calling POST /safari/session/create, you may include entry_kind in the request body (optional; defaults to web). The entry_kind cannot be changed after the session is created.

Sessions with entry_kind=im support in-place environment and team switching — the IM /env and /scope commands can rebind the session to a different execution environment (a BYOC runner or the cloud sandbox) or team scope without discarding the conversation. Console sessions (web) have their environment and team fixed at creation time and do not support in-place switching.

Reply language

Every session determines a reply language at creation time. The agent replies in that language for the entire session and never switches midway; reopening the session later continues in the same language.

Entry kind	Where the reply language comes from
Console (`web`)	Follows the console UI language when the session is created; it is fixed at creation, so switching the UI language afterward does not affect existing sessions
IM / API / automation (`im` / `api` / `automation`)	These entries carry no UI-language signal, so they default to the account’s notification language

Session data export

POST /safari/session/export streams all events from a session as NDJSON (application/x-ndjson), one JSON object per line. This is intended for auditing, archiving, offline analysis, or feeding session data into external systems.

Request fields

Field	Type	Required	Description
`session_id`	string	Yes	ID of the session to export
`include_subagents`	bool	No	When `true`, recursively includes the event streams of all subagent child sessions; defaults to `false`

Response format

The response Content-Type is application/x-ndjson. The first line is always a session_meta envelope containing the session’s metadata; subsequent lines are session events. When include_subagents=true, each subagent_dispatch line is immediately followed by the complete event stream of the child session, which also begins with its own session_meta line.

{"type":"session_meta","session_id":"s_...","app_name":"ai-sre","entry_kind":"web","started_at":"2026-09-08T08:00:00Z","ended_at":"2026-09-08T08:05:00Z","model":"deepseek-v4-pro"}   // first line: session metadata (has no seq)
{"type":"user_message","seq":1,"session_id":"s_...","content":"help me investigate this incident","ts":"2026-09-08T08:00:01Z"}   // user message
{"type":"tool_call","seq":2,"session_id":"s_...","name":"bash","input":{"command":"..."},"status":"ok","call_id":"call_abc","ts":"2026-09-08T08:00:02Z"}   // tool call (model request side)
{"type":"tool_call","seq":3,"session_id":"s_...","name":"bash","output":"...","output_bytes":123,"status":"ok","call_id":"call_abc","ts":"2026-09-08T08:00:03Z"}   // tool call (runtime response side)
{"type":"subagent_dispatch","seq":4,"session_id":"s_...","agent_name":"explore","call_id":"call_def","ts":"2026-09-08T08:00:04Z"}   // subagent dispatch
{"type":"session_meta","session_id":"sub-tsk_...","parent_session_id":"s_...","app_name":"ai-sre","entry_kind":"web","model":"deepseek-v4-pro"}   // child session metadata (inlined when include_subagents=true)
{"type":"user_message","seq":1,"session_id":"sub-tsk_...","content":"...","ts":"..."}   // child session events
{"type":"final_answer","seq":5,"session_id":"s_...","content":"...","usage":{"input_tokens":0,"output_tokens":0,"cache_read":0,"cache_creation":0},"ts":"2026-09-08T08:05:00Z"}   // turn-final answer

Line types

The export stream contains only the line types below (the type field); no other types occur:

Line type	When it appears	Key fields
`session_meta`	First line of every session (both the main session and inlined child sessions)	`session_id`, `account_id`, `app_name`, `parent_session_id` (child sessions), `entry_kind` (`web` / `im` / `api` / `automation`; empty normalized to `web`), `started_at` / `ended_at` (session created / updated time), `model`
`user_message`	User message events	`content` (extracted text: multiple text parts joined with `\n`; reasoning / thought parts skipped; user rows never carry `usage`)
`system_reminder`	User rows whose text starts with `<system-reminder>`	`content` (harness context injected by the system — locale / env / knowledge / memory / channel-guide / mount — not something you typed)
`tool_call`	Model tool request (`function_call` part) or runtime response (`function_response` part), one line per part	Request side: `name`, `input` (args object), `status` (optimistically `ok`), `call_id`; response side: `name`, `output` (response JSON serialized to a string), `output_bytes`, `status` (`ok` / `error`; a row-level error also carries `error`), `call_id`
`subagent_dispatch`	Model initiates an `agent_dispatch` call (one line per call)	`agent_name`, `call_id`; with `include_subagents=true` the child’s full event stream is inlined right after this line
`final_answer`	Turn-complete assistant event (takes priority over `llm_call`)	`content`, `usage`
`llm_call`	Text-only model response that carries token usage	`content`, `usage`, `model`, `ended_at`
`agent_text`	Assistant prose with no usage and not turn-complete (fallback type)	`content`
`session_fork`	The “Forked from conversation” divider row	`content`
`error`	Appended at the end of the stream when an error occurs after streaming started, or inlined when a child session is unavailable under `include_subagents`	`content` (error text; consumers must inspect this line to tell whether the stream completed — see the Warning below)

Fields and behavioral conventions

seq: a monotonic counter over lines emitted, starting at 1 (reset per child session; never reset across pages). When one DB event yields several lines (see below), the lines are numbered consecutively in part order. session_meta lines carry no seq.
call_id (the pairing key): the ADK function_call / function_response id (both sides of a call share the same id). A single model response can bundle several tool calls into one DB event (e.g. 2 agent_dispatch calls + 1 bash call in the same event); the export emits one line per part, in the original part order, and call_id lets a consumer re-pair a response line with its call line without relying on emission order.
usage (token counts): per-event totals (input_tokens / output_tokens / cache_read / cache_creation), emitted as 0 rather than omitted when absent. It is stamped on the first line of the event only — the lines of a batched dispatch share one usage figure, so a consumer that sums per line is not over-counted N times.
model: the model on session_meta and llm_call lines is the session’s own bound chatmodel (set on the first turn’s weighted pool draw and on any later failover rebind), which can and does disagree with the app’s static config default (e.g. config default qwen, the session’s actual model deepseek); sessions that never bound one fall back to the app config default, and unregistered apps get an empty value.
Timing: ts is the event’s write time (RFC 3339). llm_call and tool_call lines use it as an approximation of the end time (ended_at); start times and durations (started_at / duration_ms) are not provided (empty / 0).
include_subagents=true: each subagent_dispatch line is immediately followed by the child session’s complete export stream, recursively (every dispatch line of a batch is inlined, not just the first); the child’s seq restarts at 1 and its session_meta carries parent_session_id. If a child session is missing or fails to export, the parent stream is not interrupted — an inlined error line is emitted and the stream continues.
Some bookkeeping rows produce no export line (e.g. OAuth-authorized markers), so the line count can be lower than the session’s event count.

If an error occurs after streaming has already begun, the server cannot switch to a standard JSON error envelope. Instead, a JSON-encoded error object is appended as the final line of the stream. Consumers must inspect this last line to determine whether the stream completed successfully.

Permissions: the export endpoint uses the same access gate as sending messages (CanChatSession), meaning the caller must have message-send permission on the session — read-only access is not sufficient. Personal sessions can be exported only by their creator; team sessions can be exported by same-account members who can access the session.

Overview

Learn about AI SRE’s positioning, capabilities, and use cases.

Usage Insights

Generate team incident-handling and operational insights from session data.

Manage Knowledge

Provide domain knowledge to sessions, loaded by team and mounted on demand across teams.

Skills

Reusable skills invoked via slash commands.

MCP (External Tools)

Connect external systems via MCP to extend the agent’s tool capabilities.

IM Platform

Mention the agent in Slack / Feishu / DingTalk / WeCom to troubleshoot, with automatic war-room diagnosis.

​Overview

​Creating and Managing Sessions

​Search and Filter

​Session Visibility and Permissions

​Sharing a Session

​Per-Session Actions

​List Status Indicators

​Sending Messages and Streaming Responses

​Attachments and Context References

​Real-Time Streaming Output

​Queueing Messages While Running

​Environment Initialization

​Tool Calls and Artifacts

​Todo List

​Agent Questions

​When Authorization Is Required

​Subagents

​Task Panel and Background Tasks

​Artifacts Preview

​Status Page Update Drafts

​What’s on the draft card

​Card states

​Handoff URL for review

​Tool specifics

​Message Actions

​Forking a session

​Session Feedback

​Context Compaction

​What You Will See

​Choosing a Runtime Environment

​Binding a Team

​Session entry kind

​Reply language

​Session data export

​Request fields

​Response format

​Line types

​Fields and behavioral conventions

​Related Pages

Overview

Usage Insights

Manage Knowledge

Skills

MCP (External Tools)

IM Platform

Overview

Creating and Managing Sessions

Search and Filter

Session Visibility and Permissions

Sharing a Session

Per-Session Actions

List Status Indicators

Sending Messages and Streaming Responses

Attachments and Context References

Real-Time Streaming Output

Queueing Messages While Running

Environment Initialization

Tool Calls and Artifacts

Todo List

Agent Questions

When Authorization Is Required

Subagents

Task Panel and Background Tasks

Artifacts Preview

Status Page Update Drafts

What’s on the draft card

Card states

Handoff URL for review

Tool specifics

Message Actions

Forking a session

Session Feedback

Context Compaction

What You Will See

Choosing a Runtime Environment

Binding a Team

Session entry kind

Reply language

Session data export

Request fields

Response format

Line types

Fields and behavioral conventions

Related Pages