mastra-ai/mastra · error · Error

Timed out waiting for database to become ready (last status:

Error message

Timed out waiting for database to become ready (last status: ${db.status}). Check again with: mastra env db show ${dbId}

What it means

pollDatabaseUntilReady gives up after maxWaitMs elapsed without the database reaching 'ready'. The thrown message includes the last observed status and a ready-made recovery command (`mastra env db show <dbId>`). This is a timeout, not a hard failure: provisioning may simply be slow and could complete later.

Source

Thrown at packages/cli/src/commands/db/platform-api.ts:220

      opts?.onStatus?.(db.status);
    }

    if (db.status === 'ready') {
      return db;
    }

    if (db.status === 'failed') {
      throw new Error(`Database provisioning failed${db.error ? `: ${db.error}` : ' (no error detail from provider)'}`);
    }

    if (db.status === 'deleting' || db.status === 'deleted') {
      throw new Error(
        `Database was ${db.status === 'deleted' ? 'deleted' : 'scheduled for deletion'} while provisioning`,
      );
    }

    if (Date.now() - start >= maxWaitMs) {
      throw new Error(
        `Timed out waiting for database to become ready (last status: ${db.status}). ` +
          `Check again with: mastra env db show ${dbId}`,
      );
    }

    await new Promise(resolve => setTimeout(resolve, intervalMs));
  }
}

View on GitHub (pinned to 75dd419e61)

Solutions

Wait a few minutes, then run `mastra env db show <dbId>` (as the error suggests) to check whether it became ready
Re-run the create/show command; if the database is now ready, continue your workflow
Retry creation in a less loaded region or with a smaller instance size if timeouts repeat
Increase the wait budget (maxWaitMs) if you provision routinely-slow database tiers

Example fix

// before
// default poll: timed out with last status 'creating'
// after
mastra env db show <dbId>   // confirm status: ready, then proceed

Defensive patterns

Strategy: retry

Validate before calling

// Estimate a generous wait based on known provisioning SLAs before polling
const expectedReadyMs = 5 * 60 * 1000;
if (maxWaitMs < expectedReadyMs) console.warn('maxWaitMs below typical provisioning time; timeouts likely');

Type guard

function isProvisionTimeout(err: unknown): err is Error {
  return err instanceof Error && err.message.startsWith('Timed out waiting for database to become ready');
}

Try / catch

try {
  const db = await createDatabase(opts);
} catch (err) {
  if (isProvisionTimeout(err)) {
    // poll once more via `mastra env db show <dbId>` after a grace period instead of failing the job
  } else throw err;
}

Prevention

Set maxWaitMs comfortably above the provider's typical provisioning time
After timeout, always check status with `mastra env db show <dbId>` before re-creating
Avoid re-creating on timeout — the database may still become ready
Watch for repeated regional slowness and switch regions proactively

When it happens

Trigger: createDatabase -> pollDatabaseUntilReady loop where Date.now() - start >= maxWaitMs while db.status is still something other than 'ready'/'failed'/'deleting'/'deleted' (typically 'creating' or 'provisioning').

Common situations: Provider slowdowns or degraded capacity in a busy region; large instance sizes taking longer than the default wait; intermittent network latency between CLI and API slowing polls.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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