# ServiceControl Error instances

A ServiceControl Error instance:

* Monitors [the central `error` queue](/nservicebus/recoverability/configure-error-handling.md#error-queue-monitoring) and stores the failed messages, making them available for manual retries using [ServicePulse](/servicepulse/intro-failed-messages.md).
* Aggregates and forwards data from [Audit instances](/servicecontrol/audit-instances/index.md) for visualization in [ServicePulse](/servicepulse/index.md).
* Collects and serves [heartbeat](/monitoring/heartbeats/index.md) and [custom check](/monitoring/custom-checks/index.md) data for presentation by [ServicePulse](/servicepulse/health-check-notifications.md).
* Publishes [integration events](/servicecontrol/contracts.md) that can be handled by user-built [endpoints](/nservicebus/messaging/publish-subscribe/publish-handle-event.md) that can perform a custom action when those events occur.
* Forwards failed messages to an [error log queue](/servicecontrol/errorlog-auditlog-behavior.md) for custom processing if [configured](/servicecontrol/servicecontrol-instances/configuration.md#transport-servicecontrolforwarderrormessages) to do so.

## Persistence

Each ServiceControl Error instance stores message data in a RavenDB database. For instances deployed using the [ServiceControl Management Utility](/servicecontrol/servicecontrol-instances/deployment/scmu.md) or [PowerShell](/servicecontrol/servicecontrol-instances/deployment/powershell.md), this database is embedded with the ServiceControl Error instance. For ServiceControl Error instances deployed using [containers](/servicecontrol/servicecontrol-instances/deployment/containers.md), the database resides in a [separate container](/servicecontrol/ravendb/containers.md).

Failed message data is retained until 7 days after successful retry is detected or the failed message is [manually archived](/servicepulse/intro-archived-messages.md). [This retention period can be customized](/servicecontrol/servicecontrol-instances/configuration.md#data-retention).

> [!WARNING]
> The ServiceControl RavenDB server and databases are used exclusively by ServiceControl and are not intended for external manipulation or modifications.

## Notifications

### Health monitoring

ServiceControl includes some basic self-monitoring implemented as [custom checks](/monitoring/custom-checks/index.md). These checks are reported in ServicePulse along with other custom checks.

#### MSMQ transactional dead letter queue

A machine running MSMQ has a single transactional dead letter queue. Messages that cannot be delivered to queues located on remote machines are eventually moved to the transactional dead letter queue. ServiceControl monitors the transactional dead letter queue on the machine it is installed on. The presence of messages in this queue may indicate problems delivering messages for retries.

#### Azure Service Bus staging dead letter queue

Every Azure Service Bus queue has an associated dead letter queue. When ServiceControl sends a message for retry, it uses a staging queue. ServiceControl monitors the dead letter queue associated with the staging queue. The presence of messages in the dead letter queue indicates problems delivering messages for retries.

#### Failed imports

When ServiceControl is unable to ingest an audit or error message, an error is logged and the message is stored separately. ServiceControl monitors these messages. For more information, see [re-importing failed messages](/servicecontrol/import-failed-messages.md).

#### Error message ingestion process

When ServiceControl has difficulty connecting to the configured transport, the error message ingestion process is shut down for sixty seconds. These shutdowns are monitored. The time to wait before restarting the error ingestion process is controlled by the [ServiceControl/TimeToRestartErrorIngestionAfterFailure](/servicecontrol/servicecontrol-instances/configuration.md#recoverability-servicecontroltimetorestarterroringestionafterfailure) setting.

#### Message database storage space

ServiceControl stores messages in an embedded database. If the drive containing the database runs out of storage space, message ingestion fails and the ServiceControl instance stops. This may cause instability in the database, even after storage space is increased. The remaining storage space on the drive is monitored. The check reports a failure if the drive has less than 20% remaining of its total capacity. This threshold is controlled by the [ServiceControl/DataSpaceRemainingThreshold](/servicecontrol/servicecontrol-instances/configuration.md#troubleshooting-servicecontroldataspaceremainingthreshold) setting.

#### Critical message database storage space

This is similar to the [Message database storage space check](#notifications-health-monitoring-message-database-storage-space). However, in this case, if the drive containing the database has less than 5% remaining of its total capacity, message ingestion on the ServiceControl instance is stopped to prevent data loss, and a failure is reported. This threshold is controlled by the [ServiceControl/MinimumStorageLeftRequiredForIngestion](/servicecontrol/servicecontrol-instances/configuration.md#troubleshooting-servicecontrolminimumstorageleftrequiredforingestion) (for the error instance) and [ServiceControl.Audit/MinimumStorageLeftRequiredForIngestion](/servicecontrol/audit-instances/configuration.md#troubleshooting-servicecontrol-auditminimumstorageleftrequiredforingestion) (for the audit instance) settings.