> ## Documentation Index
> Fetch the complete documentation index at: https://docs.headlesslabs.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Registros

> Configura la entrega de eventos de Headless, consulta el historial del servidor y revisa el diagnóstico de canales y webhooks.

Los registros de moderación y del servidor se guardan por servidor y pueden enviarse a un canal general o a destinos distintos por categoría y evento. El comando de reportes de miembros tiene su propio destino y no reemplaza los registros generales.

## Destinos y prioridad de rutas

Usa `.logs set #canal` para establecer el canal general. Headless entrega registros exclusivamente mediante webhooks; si no puede enviarlos, los deja pendientes de reintento y no usa `channel.send` como alternativa. Dashboard → Logs permite configurar destinos por categoría y por evento. El envío activo aplica esta prioridad: ruta específica del evento → ruta de categoría → canal general. Si el destino específico no existe o ya no es un canal de texto válido, continúa con la siguiente ruta configurada.

Las categorías actuales abarcan moderación, mensajes, canales, roles, miembros, servidor, configuración, sorteos, minijuegos, seguridad y bot. `.logs off` quita el canal general y la URL de webhook manual. No borra el historial ni las rutas separadas que se configuraron en Dashboard.

## Setup, estado y diagnóstico

Los comandos de prefijo se ejecutan con el prefijo configurado del servidor (`.` de forma predeterminada). La familia `/logs` publica `set`, `setup`, `status`, `diagnose` y `test`; no ofrece las consultas `recent`, `search` ni `export` como subcomandos slash.

`/logs setup channel:#mod-logs` guarda el destino, crea o reutiliza la webhook y envía un evento real de prueba. `.logs set #mod-logs` configura el destino e intenta crear la webhook, pero no equivale al setup slash completo. Usa `.logs diagnose` para revisar el Audit Log, webhook, permisos, intents, modo de entrega y errores recientes; `.logs test` manda una entrada real de prueba y distingue entre entrega confirmada, reintento pendiente y entrega no confirmada.

## Buscar y exportar el historial

`.logs recent [cantidad]` muestra hasta 20 entradas (10 por defecto). Usa una cantidad positiva: el runtime no normaliza valores negativos. `.logs search <consulta>` busca sin distinguir mayúsculas en acción, actor, objetivo, motivo e ID y muestra hasta 15 coincidencias recientes. `recent` y `search` requieren `Moderate Members`.

El historial se mantiene aislado por servidor. El límite predeterminado es 50 000 entradas por servidor; `HEADLESS_LOG_HISTORY_LIMIT_PER_GUILD` permite ajustarlo entre 5 000 y 250 000. `.logs export` descarga como JSON los registros guardados de ese servidor y requiere `Administrator`; si el archivo supera 7 MB, el comando no lo adjunta y señala el archivo de datos local como alternativa.

## Permisos y privacidad

Los comandos de configuración, estado, diagnóstico, prueba y exportación requieren `Administrator` para quien los ejecuta; los comandos de historial requieren `Moderate Members`. En comandos prefix, las comprobaciones compatibles pueden aceptar Fake Permissions configurados por Headless; el permiso del bot nunca se sustituye por uno virtual. `/logs` publica `Administrator` como permiso predeterminado y el control local de Headless vuelve a comprobarlo.

Para atribuir eventos, el bot necesita `View Audit Log`. Para crear o reparar webhooks necesita `Manage Webhooks`. El transporte de registros es webhook-only y no tiene fallback a `channel.send`; los permisos de mensaje del bot no convierten una entrega fallida en una entrega confirmada. El diagnóstico informa de permisos de webhook y de los intents disponibles de miembros y contenido de mensajes.

La URL de una webhook es una credencial de acceso. No la publiques, la compartas en capturas ni la guardes en canales públicos. `.logs webhook clear` elimina la URL manual; si se expuso, revoca o rota también la webhook desde Discord.

## Reportes de miembros: destino separado

`.reportlogs [#canal]` configura dónde recibe el equipo los reportes enviados por miembros y requiere `Manage Server` (nativo o un permiso virtual compatible). Si no se indica canal, el comando guarda como destino el canal actual. La ruta de reportes no cambia el canal general ni las categorías/eventos de `.logs`; consulta [Moderación y reportes](/docs/security/moderation.md) para el flujo de intake.

## Pasos

**1. Elige el destino general**

Crea o selecciona un canal privado para el equipo autorizado y ejecuta `/logs setup #mod-logs` si quieres que Headless pruebe la entrega durante la configuración.

**2. Añade rutas específicas si hacen falta**

En Dashboard → Logs, configura destinos por categoría o por evento. Las rutas válidas de evento tienen prioridad sobre categoría y general.

**3. Comprueba permisos y entrega**

Ejecuta `.logs diagnose` y `.logs test`; confirma que la entrega webhook figure como confirmada. Si queda en reintento o falla, revisa `Manage Webhooks`, la ruta seleccionada y el error; no existe fallback a envío directo.

**4. Restringe consultas y exportaciones**

Da `Moderate Members` para consultar historial; reserva `Administrator` para configuración y exportación. Comparte JSON únicamente con el equipo autorizado.

## Comandos por flujo

### Destino de registros y webhook

```headless-command Syntax theme={null}
.logs set <channel>
```

```headless-command Example theme={null}
.logs set #mod-logs
```

```headless-command Syntax theme={null}
.logs webhook <url_or_clear>
```

```headless-command Example theme={null}
.logs webhook clear
```

```headless-command Syntax theme={null}
.logs off
```

```headless-command Example theme={null}
.logs off
```

### Configuración y diagnóstico slash

#### `/logs setup`

```headless-command Syntax theme={null}
/logs setup channel:<channel>
```

```headless-command Example theme={null}
/logs setup channel:#mod-logs
```

#### `.logs set`

```headless-command Syntax theme={null}
/logs set channel:<channel>
```

```headless-command Example theme={null}
/logs set channel:#mod-logs
```

#### `.logs status`

```headless-command Syntax theme={null}
/logs status
```

```headless-command Example theme={null}
/logs status
```

#### `.logs diagnose`

```headless-command Syntax theme={null}
/logs diagnose
```

```headless-command Example theme={null}
/logs diagnose
```

#### `.logs test`

```headless-command Syntax theme={null}
/logs test
```

```headless-command Example theme={null}
/logs test
```

### Consulta y exportación de historial

```headless-command Syntax theme={null}
.logs recent [amount=10]
```

```headless-command Example theme={null}
.logs recent 10
```

```headless-command Syntax theme={null}
.logs search <query>
```

```headless-command Example theme={null}
.logs search ban
```

```headless-command Syntax theme={null}
.logs export
```

```headless-command Example theme={null}
.logs export
```

### Destino de reportes de miembros

```headless-command Syntax theme={null}
.reportlogs [channel]
```

```headless-command Example theme={null}
.reportlogs #private-reports
```

También funciona: `.reportlogs`

> [!WARNING]
>
> Una exportación puede contener nombres, motivos, IDs y metadatos de moderación. La webhook permite publicar como el bot: guárdala como secreto y limita el acceso a los archivos exportados. No uses `.logs recent` con una cantidad negativa.

**Nota:**

El registro de evento enviado por `/logs setup` es real, pero es una entrada de diagnóstico `config_change`, no una sanción ni un evento de moderación. `.logs test` también prueba la entrega creando una entrada de registro.

## Páginas relacionadas

* [Casos de moderación](/docs/moderation/cases.md)
* [Moderación y reportes](/docs/security/moderation.md)
* [Permisos de Headless](/docs/permissions.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.