What causes "Failed to stream logs: ${resp.status} — ${text}" in mastra-ai/mastra?

Check the status code and body in the message for the server's reason.

mastra-ai/mastra · error · Error

Failed to stream logs: ${resp.status} — ${text}

Error message

Failed to stream logs: ${resp.status} — ${text}

What it means

Thrown by streamLogs when the HTTP response for the SSE log stream is not ok (non-2xx). The CLI reads the response body as text and embeds the status code and body in the error so the developer can see the server's rejection reason before any streaming begins.

Source

Thrown at packages/cli/src/commands/studio/deploy-logs.ts:39

    }
  } else {
    console.info('(no logs available)');
  }
}

async function streamLogs(deployId: string, token: string, orgId: string) {
  const url = `${MASTRA_PLATFORM_API_URL}/v1/studio/deploys/${deployId}/logs/stream`;

  const resp = await platformFetch(url, {
    headers: {
      ...authHeaders(token, orgId),
      Accept: 'text/event-stream',
    },
  });

  if (!resp.ok) {
    const text = await resp.text();
    throw new Error(`Failed to stream logs: ${resp.status} — ${text}`);
  }

  if (!resp.body) {
    throw new Error('No response body for log stream');
  }

  const reader = resp.body.getReader();
  const decoder = new TextDecoder();
  let buffer = '';

  // Handle Ctrl+C gracefully
  process.on('SIGINT', () => {
    void reader.cancel();
    process.exit(0);
  });

  while (true) {
    const { done, value } = await reader.read();

View on GitHub (pinned to 75dd419e61)

Solutions

Check the status code and body in the message for the server's reason.
Re-authenticate if the status is 401/403.
Confirm the deploy ID exists and is accessible from your organization.
Retry if the status is 5xx, or use the non-streaming logs command as a fallback.

Defensive patterns

Strategy: fallback

Try / catch

try {
  await streamLogs(deployId, token);
} catch (err) {
  if ((err as Error).message.startsWith('Failed to stream logs:')) {
    console.error(err.message);
    // fall back to the non-streaming logs endpoint
    await getLogs(deployId);
    return;
  }
  throw err;
}

Prevention

Fall back to the non-streaming logs command when SSE fails.
Keep auth tokens fresh — 401/403 are the most common stream rejections.
Verify network/proxy policies allow text/event-stream responses.
Use the fallback path automatically in scripts wrapping the CLI.

When it happens

Trigger: Opening the log stream endpoint when the server responds 401/403 (bad token or no access), 404 (unknown deploy ID), or 5xx (platform error) instead of upgrading to a text/event-stream.

Common situations: Expired CLI auth mid-session; deploy ID from another org; deploy logs endpoint temporarily unavailable during platform maintenance; proxy/firewall intercepting the event-stream request and returning an error page.

Related errors

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/063ec49977f51e92. Report an issue: GitHub.