Operations

Operational behaviors and controls for GitTinkerer deployments.

Pause enforcement

• Repository pauses are enforced before spawning runs (webhook and API flows).
• Paused repos are stored in paused_repos (and per-user pauses in paused_run_targets when used); runs targeting paused entries are rejected before the runner starts.
• The admin UI (/admin) is the primary surface to pause/resume repositories.

Retry behavior

• Retries reuse the original payload and respect the current pause state.
• When possible, retries attempt to mint a GitHub installation token; failures are surfaced in the run status and Sentry.
• Use the admin UI to trigger retries for failed runs.

Rate limiting

• Rate-limit headers (x-rate-limit-remaining, x-rate-limit-reset) are returned on run submissions.
• Redis-backed counters enforce REPO_RATE_LIMIT_MAX_REQUESTS and REPO_RATE_LIMIT_WINDOW_SECONDS (see DEVELOPMENT.md for configuration).

Monitoring and telemetry

• Sentry captures service errors (migrations, Redis init, GitHub auth, run spawn, request crashes) and bash failures with tags for run_id, repo, stage, and user/installation.
• Analytics endpoints expose usage metrics and CSV export: GET /api/analytics/usage and GET /api/analytics/export.