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

# Capacity, monitoring, and recovery

> Monitor bucket usage, handle temporary service responses, protect critical objects, and validate application recovery.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Give applications and operators a concrete S2 reliability runbook based on the public service contract and observable behavior.

## Prerequisites

* An S2-backed production workload
* An application recovery plan that identifies critical objects

## Workflow

<Steps>
  <Step>
    Monitor bucket bytes, object counts, request errors, bandwidth, and quota headroom.
  </Step>

  <Step>
    Alert on sustained error rates, repeated throttling, and unexpected changes in object inventory.
  </Step>

  <Step>
    Keep application retry behavior bounded and safe for idempotent object operations.
  </Step>

  <Step>
    Use version restore for accidental overwrites and the StackShift recovery process for service-level incidents.
  </Step>

  <Step>
    Verify critical keys, sizes, and checksums before declaring application recovery complete.
  </Step>
</Steps>

## What to monitor

* Current bytes and object count compared with the bucket and plan quota.
* Request volume, error count, bandwidth, and top prefixes from bucket analytics.
* Recent access-log status codes and request identifiers when an application reports a failure.
* Lifecycle-rule errors, event-delivery retries, and inventory-export failures.
* Unexpected inventory differences for application-critical prefixes.

## Application behavior during an incident

* Use exponential backoff with jitter for temporary `503 ServiceUnavailable` and `429 SlowDown` responses.
* Honor `Retry-After` when it is present and stop after a bounded number of attempts or an application deadline.
* Retry reads freely when they have no side effects. Retry writes only when the key, body, checksum, and precondition make the operation idempotent.
* Do not automatically retry authentication, authorization, invalid-request, retention, or quota errors without correcting their cause.
* Surface a degraded state to callers instead of silently dropping uploads or inventing a successful object record.

## Recovery validation

A bucket returning traffic again is only the start of recovery validation. Compare the expected inventory for critical prefixes, then verify object sizes and SHA-256 checksums for records the application cannot recreate.

Keep object identifiers and expected checksums in the application database when business workflows must reconcile stored files. S2 object metadata is useful for storage operations, but it should not replace the application record that explains why an object exists.

## Recovery controls

* Restore a selected object version after an accidental overwrite or delete when versioning was enabled before the event.
* Use inventory exports to compare large keyspaces without loading every object body.
* Use retention rules for deletion protection and lifecycle rules for intentional aging; neither replaces recovery testing.
* Rotate any access key that may have been exposed during investigation and review access logs for its activity.
* Resume writes only after the application has passed its own read, write, list, and checksum checks.

## Expected result

<Check>
  The application fails predictably during a storage incident and operators can prove that critical data is correct after recovery.
</Check>

## Common failures

<Warning>
  * Retrying every failure without a maximum attempt count, timeout, jitter, or idempotency rule.
  * Treating a successful HTTP response as sufficient recovery proof without checking the expected object checksum.
  * Monitoring only stored bytes while ignoring object count, request errors, and bandwidth changes.
  * Using versioning as the only backup or restore strategy for business-critical application records.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="S2 object storage overview" href="/object-storage/overview">
    Understand the S3-compatible S2 surface, its bucket model, security boundaries, data controls, and application workflows.
  </Card>

  <Card title="Versioning, lifecycle, and retention" href="/object-storage/versioning-lifecycle-and-retention">
    Protect object history, restore earlier versions, automate aging policies, and prevent protected objects from being deleted too early.
  </Card>

  <Card title="Events, analytics, inventory, and websites" href="/object-storage/events-analytics-and-websites">
    Connect object changes to application workflows, inspect bucket activity, export inventories, query catalogs, and publish static content.
  </Card>

  <Card title="Alerts view" href="/operations/alerts-view">
    Use alerts to focus on active operational problems instead of scanning every resource manually.
  </Card>
</CardGroup>