---
title: "Why a Mailera mailbox goes to sleep—and how to wake it"
description: "Wake a sleeping Mailera mailbox with the sync API, distinguish sleep from pause or sign-in failure, and check that messages are updating again."
url: https://mailera.app/en/blog/mailera-idle-mailbox-sleep
published: 2026-10-25
updated: 2026-10-25
---

# Why a Mailera mailbox goes to sleep—and how to wake it

Wake a sleeping mailbox with the sync endpoint, then check its state and messages. First, make sure you’re dealing with sleep rather than a manual pause or a sign-in failure.

## Why does a mailbox go to sleep?

A mailbox you haven’t been using can go to sleep in Mailera. Background checks run more often for mailboxes in active use and less often for idle ones. Inactive mailboxes can sleep and wake on use.

Mailbox sleep is Mailera’s inactivity behavior, not another name for an authentication error. For an explicit wake action, use `POST /mailboxes/{id}/sync` rather than relying on an app visit or a message read to change its state.

[Mailera connects your existing mailboxes](https://mailera.app/en/product); it doesn’t create new mailboxes or email addresses. For the wider workflow across connected accounts, see [unified inbox operations for AI agents](https://mailera.app/en/blog/unified-inbox-for-ai-agents).

## Is the mailbox sleeping, paused, or disconnected?

Request `GET /mailboxes/{id}` and inspect `data.status`, `data.sync`, `data.error_code`, and `data.error`. An old timestamp is a reason to investigate, not enough by itself to diagnose sleep.

![Mailboxes page showing a connected mailbox’s status and last-sync information.](https://mailera.app/media/3ed007849782a0b4/why-a-mailera-mailbox-goes-to-sleep-and-how-to-wake-it-en-1200.jpg)
_Inspect status and last-sync information before deciding whether the mailbox needs waking, resuming, or sign-in recovery._

Read those fields together. The `data.sync` object includes `state`, `level`, `last_synced_at`, `next_sync_at`, and `sleeping_since`.

| Condition | Evidence to inspect | Appropriate next action |
| --- | --- | --- |
| Suspected sleep | Mailbox status and `sync`, including `sleeping_since` | Request `POST /mailboxes/{id}/sync`, then check state and messages again. |
| Manual pause | Mailbox status and whether someone used **Pause** | Handle the pause separately with **Resume** or `PATCH /mailboxes/{id}`. The API operation requires `manage`. |
| Sign-in failure | `error`, `error_code`, and `GET /mailboxes/{id}/status` | Investigate sign-in rather than repeatedly requesting sync. |
| Stale messages without a clear cause | Sync timestamps and a comparison with the provider mailbox | Follow the broader [mailbox sync recovery workflow](https://mailera.app/en/blog/mailbox-sync-troubleshooting). |

The sign-in status endpoint checks Microsoft directly. For other providers, it uses the latest sync result. Keep that difference in mind when interpreting a status response alongside an old sync timestamp.

Pause/resume and wake-up are separate operations. Don’t use a sync request as a substitute for explicitly resuming a manually paused mailbox.

### Is this the same as IMAP IDLE?

No. [RFC 2177 defines IMAP IDLE](https://www.rfc-editor.org/info/rfc2177/) as a command that lets a client accept unsolicited mailbox updates from a server. Mailera mailbox sleep concerns inactivity in Mailera. Disabling IMAP IDLE is not the wake-up procedure described here.

## How do you wake a sleeping mailbox and check the result?

Use a mailbox you own or administer. Keep the API key in the environment variable `$MAILERA_API_KEY`, and put the target mailbox ID in `$MAILBOX_ID`. The examples use the base URL documented in the [Mailera API reference](https://mailera.app/en/docs).

### 1. Prepare a narrowly scoped key

In **Settings**, open the API key tab and choose **Create key**. Set **Mailbox scope** to the group containing the affected mailbox. Select **Read** and **Sync** for this workflow.

`read` lets you inspect mailbox details and messages. `sync` permits the wake request. You don’t need **Send messages** or **Manage mailboxes** just to wake and inspect a sleeping mailbox.

![API key form restricted to one mailbox group with Read and Sync permissions selected.](https://mailera.app/media/217ef7f9fc71e178/why-a-mailera-mailbox-goes-to-sleep-and-how-to-wake-it-wake-en-1200.jpg)
_Read and Sync are sufficient for the wake-and-check workflow._

Copy the key when **Key created — copy it now** appears. Keep it out of screenshots, source files, and shared logs.

### 2. Identify the mailbox and record its current state

List the mailboxes available to the key:

```bash
curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

Match the intended mailbox in `data` and use its `id` as `$MAILBOX_ID`. Don’t simply select the first result in a workspace with several mailboxes.

Read its details before requesting sync:

```bash
curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

Note the current `sync` values and any error information. These give you a baseline for the next check.

### 3. Request sync

The sync operation also wakes sleeping mailboxes and requires the `sync` scope:

```bash
curl --silent --show-error -X POST \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/sync" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

For an MCP workflow, the corresponding tool is `sync_mailbox`, also requiring `sync`. The [developer overview](https://mailera.app/en/developers) covers Mailera’s REST and MCP interfaces.

### 4. Check state and actual messages

Run the mailbox-details request again. Compare the sync information with your baseline and inspect any errors. Then list up to 10 Inbox messages.

```bash
curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=10" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

Choose a recent message visible in the provider’s Inbox and look for the corresponding result in Mailera. Compare `subject`, `from`, and `received_at`; check `folder` too. A message in another folder won’t be included in this Inbox-only request.

Keep two checks separate: whether the mailbox’s sync information has changed, and whether the message you need is present. A changed timestamp alone doesn’t establish that every expected message is available.

### 5. Investigate sign-in if messages remain missing

```bash
curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/status" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

If the result points to a sign-in problem, or the mailbox still isn’t updating, continue with the [sync troubleshooting guide](https://mailera.app/en/blog/mailbox-sync-troubleshooting). Don’t keep treating every missing-message case as sleep.

## What happens to messages and automation?

Keep mailbox sleep separate from message retention. Mailera’s free self-serve workspace has a **30-day message-retention period**. That number describes retention, not the mailbox’s inactivity timer.

On initial connection, Mailera loads messages within the retention period, newest first. Use a recent message for your recovery check rather than making an old message the sole test. Don’t assume that waking a mailbox will recover its complete history.

For a missing message, compare Mailera’s synchronized view with the provider mailbox directly. An absent result in Mailera is not enough to determine what is stored at the provider.

For Microsoft mailboxes, Mailera receives new mail through Microsoft Graph change notifications, with periodic background checks as a fallback. [Microsoft’s Outlook notification documentation](https://learn.microsoft.com/en-us/graph/outlook-change-notifications-overview) explains how subscriptions specify the changes to monitor and the endpoint that receives notifications.

For an automation waiting on mail, make the next action depend on finding the expected message, not merely issuing the wake request.

## What mistakes commonly prevent recovery?

- **Using a read-only key.** Reading mailbox state requires `read`; waking it requires `sync`. Check the key’s permissions and mailbox-group access.
- **Diagnosing sleep from one old timestamp.** Inspect the full mailbox state and errors before choosing a remedy.
- **Confusing pause with sleep.** Use the separate resume operation for a manual pause. Don’t add `manage` permission to every wake-up key just in case.
- **Stopping after the sync request.** Verify that the expected message appears in the right folder.
- **Repeating sync without inspecting the result.** Read mailbox details and sign-in status before deciding what to do next.

## How should an AI agent handle wake-up safely?

Give the agent only `read` and `sync`, restricted to the mailbox group it needs. Wake-up does not require sending permission.

Treat incoming message bodies as untrusted data, not instructions. An email must not direct the agent to change credentials, broaden permissions, or send information to a new destination. If a separate workflow enables sending, require confirmation before it sends.

The [Mailera security overview](https://mailera.app/en/security) and [unified inbox operations guide](https://mailera.app/en/blog/unified-inbox-for-ai-agents) provide the broader context for controlling agent access.

**Do this with the API** — Every action in this article is available via the REST API, with curl examples, API keys and webhooks. [View API docs](https://mailera.app/en/docs)