Log schema contract

Bloodraven emits structured JSON logs from both the operator (bloodraven) and the per-MySQL sidecar (bloodraven-sidecar). This page is the contract that downstream log pipelines key off of: which fields are stable, what the msg values are for the events you care about, and what guarantees we make about changing them.

If you only need one rule of thumb: filter on msg for the event vocabulary in the Event reference below — those strings are stable. Everything else is best-effort.

Streams

Both binaries write to stdout. There are two independent JSON streams; you can tell them apart by the presence of certain keys.

The contract on this page applies to the operational stream. The controller-runtime stream is emitted as-is by upstream sigs.k8s.io/controller-runtime and inherits whatever shape that library produces — we don't redefine it.

To filter to operational logs in most pipelines, key on the presence of the time field (slog) or the absence of the logger field (zap).

Common fields

Every record in the operational stream carries:

Records emitted under a specific failover group also carry:

Sidecar records additionally carry:

Levels

DEBUG records may appear or disappear without notice. INFO/WARN/ERROR msg strings listed below are stable.

Field naming convention

• Keys are camelCase. Common keys: site, fg, error, peer, count, source, donor, recipient.
• The deployment API's duration_ms is an explicit contract exception: a JSON number in milliseconds, not durationMs. Its group identity is group plus namespace, rather than requiring fg.
• Site identifiers (site, oldPrimary, newPrimary, promotedSite, donor, recipient, activeSite, authoritativeActiveSite) all carry the bare site name as defined in spec.sites[].name.
• GTID fields (promotionGtid, divergentGtid, oldPrimaryGtid, newPrimaryGtid, followerGtid, activeGtid, extraGtid) carry MySQL GTID-set strings exactly as MySQL returns them — never parsed or canonicalised. Computed sets (divergentGtid, extraGtid) are MySQL-format sets; on the handoff, picker, ordered-update and promotion records they are truncated to 1024 characters with a trailing ….
• Counts (count, divergentTransactions, extraTransactions, attempt, maxRetries) are JSON numbers, not strings.
• Durations (leaseTimeout, pollInterval, delay, timeout) are emitted by slog's default time.Duration rendering — currently a string like "30s". Treat as opaque if you need to parse, prefer the metric of the same name.

Event reference

This is the stable vocabulary. msg strings here will not change without a deprecation note in the release notes.

Deployment API

Every /deploy/v1 request emits one record, including authentication and authorization refusals. Filter on the exact msg, not on HTTP paths that can contain caller-provided identifiers.

handler identifies the route handler; group, instance, namespace, and operationId are strings (empty when not resolved or not applicable). instance is the MysqlDatabase resource name. status is the numeric HTTP status, and duration_ms is numeric elapsed milliseconds. No bearer token, lease token, or token hash is logged. Treat unresolved request identifiers as untrusted input, not proof of authorization.

Requests increment bloodraven_http_requests_total{server="deploy"}. Lease revocations emit Kubernetes Event DeploymentLeaseRevoked on the MFG and increment bloodraven_deploy_lease_revocations_total{group,kind,reason} with TopologyChanged or OperatorRevoked. A planned hold is visible as Deferred/DeploymentHold, PlannedFailoverDeferred, and bloodraven_planned_failovers_deferred_total{group,reason}. See Deployment API metrics for the complete lease metric family.

Failover

The four events that trace one failover, in order:

Supporting events emitted inside Execute:

Ordered update handoff

Emitted by ExecuteHandoff when an OrderedUpdate rollout hands the primary role from the healthy active site to its standby. On success the handoff also emits failover complete (see Failover); the emergency-path Execute messages above are not emitted.

Emitted by the ordered update itself:

Planned failover

Emitted by a planned failover run. Every record names the run with runId, the value of status.plannedFailover.runID (and of the hold acknowledgement). Two emitters produce them:

• Engine records come from the reconciler that drives the run and are written through the reconciler's logger, so they carry the controller-runtime shape (ts, logger, controller, reconcileID) besides the fields below.
• Topology records come from the group's topology manager on the operational stream. Their fg comes from the manager's logger and is namespace/name, as on engine records. (Earlier releases also appended the bare group name as a second fg key; none does now.)

Some events are logged by both, as noted. Filter on msg and runId.

Retry and bookkeeping records, all engine at INFO. Each means the pass did not complete a step and requeues; repeats for minutes deserve a look:

outcome on these is the write outcome (Committed, Conflict, NotCommitted, Unknown, Gone), not a run outcome. A status write that conflicts on all three attempts of a pass counts toward the 2-minute status stall like an Unknown or NotCommitted one. Earlier releases logged no planned failover: … records, so none was renamed.

One reconciler record belongs to planned failover without the prefix:

Divergence and recovery

Fired when the operator inspects a returning old primary (after an emergency failover, or an old active site an ordered update refused to repoint), and by the replica GTID audit, which checks every read-only follower with a replication channel against the confirmed primary about every 30 seconds (and on the first poll after start, after the primary changes or is replaced under the same name, and after a completed promotion, handoff or re-assert; a refused divergent handoff candidate is audited on the next poll), whatever its replication threads report.

Kubernetes Event reasons, status conditions and planned-failover reasons for divergence:

Replication source convergence

After topology changes, Bloodraven verifies that every follower replicates directly from the uniquely confirmed active primary. These events cover candidate, DisasterRecovery, and ReadOnly followers; they are separate from the old-primary recovery events above.

Stable stage values include pre-stop-gtid, post-stop-gtid, stop, change-source, start, and verify. A follower awaiting its post-restore reclone (status.restoreReclones.pending) is not converged: its status reads Pending with reason RestorePeerHold and no convergence event is logged. Use the status sourceConvergenceState and sourceConvergenceReason for current state; use these logs for the detailed failure and GTID evidence.

Bootstrap and reclone

starting bootstrap is the single canonical event for "we are about to clone a replica". The source field disambiguates why:

A bootstrap is not started while another actor holds the sites (a planned failover, an ordered update, a promotion, an in-place restore, or a replaced topology manager still changing them); it is retried on a later poll. bootstrap deferred: another topology change holds the sites appears only when that actor claimed the sites while the bootstrap was being prepared; reason names it.

clone returned expected connection drop, waiting for restart is not a success signal. The client connection drops both when a clone succeeds (the recipient restarts) and when it is killed or aborted after MySQL has already dropped the recipient's user data. Before configuring replication the operator reads the recipient's performance_schema.clone_status and requires a new Completed row and a non-empty gtid_executed; otherwise it re-fences the recipient and logs bootstrap failed with the clone error.

A reclone-only narrative is therefore: filter msg="starting bootstrap" AND source="reclone" for the trigger event, then watch for bootstrap completed successfully (source="reclone") or bootstrap failed (source="reclone"). The Bootstrapping condition mirrors them: True while the clone runs, then False with reason NotBootstrapping after bootstrap completed successfully, or False with reason BootstrapFailed after bootstrap failed, which also sets Degraded=True with reason BootstrapFailed until the site replicates or a new clone starts.

State transitions

Every per-site state change emits one record. Use this to replay the topology timeline.

from and to values: Unknown, Unreachable, ReadOnly, Writable (the status.sites[].state values). Mirrored by the bloodraven_state_transitions_total counter, whose labels carry the kebab-case form (unknown, unreachable, read-only, writable).

Topology decisions

Sidecar fencing

The per-MySQL sidecar emits these in its operational stream. SELF-FENCING: is a stable prefix — msg strings that begin with it indicate the sidecar wrote super_read_only=ON to its local MySQL without operator instruction.

Safety-net events. The startup safety net runs before the fencing monitor starts, and each of its MySQL writes times out after 3 s. If its fence (or, on the active site, its clear) does not complete, the fencing monitor finishes the job on the first tick where MySQL answers. The monitor also re-arms the safety net after MySQL has been unreachable for 30 s or more. Rows marked monitor come only from that deferred path. The two rows marked both can come from either path.

PITR archiver

Emitted by the sidecar's BinlogArchiver and the supervisor that builds its archive store.

archive descriptor created is logged once, by the site whose atomic create wrote <prefix>/binlogs/archive.json; a sibling that lost the race verifies the winner's descriptor silently. archive descriptor changed means a re-verification before a manifest save or retention delete found a different or missing descriptor; the site stops writing and lastError carries the refusal token. promotion recorded follows each confirmed promotion record (the first writable observation of an episode); gtidExecuted is the server's set verbatim. uploads wait for the promotion record is logged on each scan of a writable site whose current episode has no saved promotion record yet (the record could not be written, or the role probe is incomplete); the site uploads nothing until it is saved, and lastError carries the error. server incarnation reset recorded follows each saved incarnation-reset record: the server's server_uuid or server_id changed, or its gtid_executed no longer contains the site's latest record's set (a reclone, reset or replaced datadir). probeInterval bounds how long before observedAt the change happened. server incarnation changed while the sidecar was not running is logged at sidecar start, before that record, when the first observation already shows such a change against the site's latest record (latestRecordAt); uploads wait until the record is saved. archive history unsafe is logged once per sidecar process for the first violation (violation is ReplicationFilter, BinlogFilter, BinlogFormat, BinlogRowImage or CommitOrder). persist history integrity marker means the marker could not be saved yet; uploads stay blocked and the save is retried every scan. A violation found while the archive is not yet verified (or is refused) is held as a pending marker in the sidecar's pod-lifetime state directory and saved at the first verified session; remove pending history integrity marker means that file (path) could not be deleted after the save. See Archive identity.

archive binlog also reports missing/divergent history and reset guards through error; /archiver/status.lastError retains the problem and bloodraven_archiver_upload_failures increases while it persists. The original message and field keys are unchanged. Audited divergent identities persist in the manifest and block affected transactions, including discovered aliases and an otherwise unchecked last row. Bootstrap/clone observations cannot establish divergence; eligible recovery on a fresh UUID can clear foreign-source flags. Known same-source loss stays unresolved on numeric return until verified or explicit canonical recovery. Reuse guards contain verified conflicting issuance; publication order does not set them. Quarantine or a canonical-backup acknowledgement provides explicit recovery. Recovery steps are in Repair PITR history safely.

failed to init archive store is logged once per failed archive store construction attempt. It used to be a single ERROR line followed by the sidecar exiting; the sidecar now keeps running and retries with jittered backoff from 5 s doubling to at most 5 minutes, so the line repeats at most once per backoff interval. It is ERROR when the error text differs from the previous attempt's (including the first) and WARN while the same cause repeats. attempt counts from 1; retryIn is the delay before the next attempt (a duration). archive store initialized after retries follows the first success after at least one failure; failingFor is the time since the first failed attempt. A first-attempt success logs neither.

The operator's archiver poller emits two lines about the PITRArchiveReady condition. A poller that cannot read the group through the uncached API reader (when its topology manager starts, or later) leaves the persisted condition as it is until it can:

Per-upload success/failure is also reflected in the bloodraven_archiver_upload_failures and bloodraven_archiver_last_upload_timestamp_seconds metrics — prefer those for alerting.

Kubernetes Event reasons for the PITR archive:

PITRSharedArchivePrefix was removed with pointInTime.sites. The PITR replay Events (PITRReplayTruncated, PITRDivergentHistoryExcluded, PITROnHistoryTransactionsExcluded) are listed in Monitoring.

retention deferred logs reason="noRetainedBackups" or reason="backupInFlight" at INFO for normal waits. Bounded backfill with eligible work remaining also logs binlogGTIDCoverageUnknown at INFO while it schedules the next batch. archiveIssuanceUnverified at INFO means legacy/overlapping issuance checks are pending and new retirements wait. A failed issuance check logs the same reason at WARN with error, naming site/name/ID and the repair/quarantine remedy. The failure remains in /archiver/status.lastError throughout cooldown until verification succeeds or that identity is removed/quarantined. All new retirements for that site can remain deferred; monitor archive capacity. It does not itself schedule rapid retention retries. Other WARN reasons are backupMetadataUnknown (missing/malformed backup GTIDs or start times), backupGTIDCoverageUnknown (no compatible protocol/proof), and binlogGTIDCoverageUnknown (eligible files lack complete, content-bound transaction coverage with no immediately eligible backfill). Those coverage and backup deferrals retain files without themselves indicating an upload failure. Failed issuance audits do retain lastError and increase the archiver failure metric as described above.

retention: coverage unavailable warns once per failed inspection attempt; that identity waits the normal retention interval before retry. Healthy identities can continue in 30-second batches. fetch retention cutoff now logs lookup errors, including HTTP 429, at WARN with the existing error field. Throttling is per transport source IP; it cannot consume another source's group admission. A 429 has no delete authority and retries after 30 seconds; it is distinct from a successful safe-deferral response.

retention: delete object leaves a durable pending record for retry. retention: save delete acknowledgements means successful deletes could not be acknowledged; the next sweep safely repeats them. retention sweep complete keeps its cutoff, deleted, and manifest_pruned fields. For a sweep that only finishes older pending deletes without a current operator proof, cutoff is an empty string and manifest_pruned is zero. deleted counts successful, idempotent delete calls.

retention: compact retirement records means the manifest update that removes obsolete acknowledged records failed. Their durable records remain available for later scans; this does not re-upload retired data. Each site's maintenance can emit retention events while that site is a replica. Active archive counts exclude retirement records.

Data-at-rest encryption

Emitted when spec.encryptionAtRest.enabled=true. See Data-at-rest encryption for the lifecycle these events trace.

Operator events:

Sidecar events:

Kubernetes Event reasons emitted on the MysqlFailoverGroup:

Dragonfly

Bloodraven optionally co-manages per-site Dragonfly instances and emits the following events when spec.dragonfly.enabled=true. Mirrored by the bloodraven_dragonfly_site_up gauge and the bloodraven_dragonfly_promotions_total{result} counter, plus the matching Dragonfly* Kubernetes Events on the MysqlFailoverGroup.

Kubernetes Event reasons emitted on the MysqlFailoverGroup (visible via kubectl describe):

License

Offline license observation. These events never change failover or reconcile behavior. updatesUntil is an RFC3339 UTC timestamp string.

Per-group records (always include fg as namespace/name):

Process-level records for the operator default (no fg):

Kubernetes Event reasons emitted on the MysqlFailoverGroup:

Backup stamp

Emitted by bloodraven backup-stamp, which runs as the backup-stamp init container of every backup Job and again from dump.py on plaintext Jobs: with --check before the dump starts and with --end after it. Records carry subcommand="backup-stamp", and every record after the store is built carries key (the stamp's object key or path), backup and site.

Configuration failures log read backup stamp template, resolve backup stamp storage, init backup stamp store, parse serverClock.end or install backup stamp tool, also with error. Every failure fails the backup, and the container's termination message starts with backup stamp: . Times are µs RFC 3339 UTC strings.

Backup retention and verification holds

Emitted by the MysqlBackup reconciler. namespace and backup name the MysqlBackup; fg and profile are its failover group and profile names (not namespace/name, unlike the topology records above).

PITR archive bindings

Emitted by the MysqlFailoverGroup reconciler for the group's archive encryption bindings. fg is the group's name. No record carries passphrase bytes, an unkeyed digest of them, or a keyCheck. keySecretName (mysql-<group>-pitr-key-<h10>) does end in a truncated keyed digest: h10 is an HMAC, under the group's digest key, over the destination and the passphrase bytes. Without that key it reveals nothing about the passphrase, but treat it as key-derived rather than key-free (see Key snapshots).

The check Job (bloodraven pitr-archive-check) logs INFO pitr archive check (destination, role, state, reason, archiveID) and writes one termination line, which the operator parses:

BLOODRAVEN_PITR_ARCHIVE_CHECK v=2 state=<Absent|Verified|Refused> reason=<token or empty> archiveID=<id> sourceUID=<uid> sourceNamespace=<ns> sourceName=<name> destinationDigest=<64 hex>

role is Writer or Reader (BLOODRAVEN_PITR_CHECK_ROLE). Values are percent-encoded like the PITR verdict. A transient storage error is retried 5 times; the Job then exits non-zero without a line. A verdict that cannot be written to the termination log exits 4 with ERROR write the verdict to the termination log; the check fails (path, error); the operator then reports "check Job <job> failed: ..." and retries. The operator likewise retries a check that exits 0 with a line that does not parse ("check Job <job> reported a verdict line that does not parse: <parser error>").

Lifecycle

Kubernetes Event reasons emitted on the MysqlFailoverGroup:

Breaking changes

v1.7.0: PITR archive identity (#206)

• Removed messages: pitr-download's WARN stop proof scan ended at unreadable successor and WARN quarantined binlog excluded, and the anchorReason texts, which belonged to the removed per-site planner. download site binlogs is kept; its error tokens changed (see PITR Job completion and failure metadata): PITRArchiveSiteOmitted, PITRCrossSiteOrder, PITRBackupBoundUnknown and PITRArchiveFilteredHistory are gone; the archive identity, dump, frontier, divergent-history, gap and order tokens are new.
• Added Job messages: INFO dump metadata and ERROR read dump metadata (dump-meta), INFO pitr plan and the BLOODRAVEN_PITR_DIVERGENT_SET line (pitr-download). pitr-download no longer logs INFO pitr-download complete, ERROR missing required env var or ERROR parse stop-datetime; its configuration failures log invalid pitr-download config.
• Verdict: BLOODRAVEN_PITR_VERDICT v=2, followed by BLOODRAVEN_PITR_RESULT v=1 and an optional BLOODRAVEN_PITR_ON_HISTORY_EXCLUSIONS line; v=1 is gone and is refused.
• restore.py sentinels: added BLOODRAVEN_PITR_SEGMENT, BLOODRAVEN_PITR_RESULT v=1, BLOODRAVEN_PITR_DIVERGENT count=, BLOODRAVEN_PITR_DIVERGENT_SET gtids= and BLOODRAVEN_PITR_ON_HISTORY_EXCLUSIONS gtids=; removed BLOODRAVEN_PITR_NOOP; BLOODRAVEN_PITR_START and BLOODRAVEN_PITR_COMPLETE changed their fields; BLOODRAVEN_RESTORE_COMPLETE dropped its pitr* keys.
• Removed sentinel and Events: BLOODRAVEN_PITR_CROSS_SITE_UNVERIFIED, the PointInTimeCrossSiteUnverified Event and reason, and the PITRSharedArchivePrefix Event.
• Added messages: sidecar archive descriptor created, archive descriptor changed, promotion recorded, uploads wait for the promotion record, archive history unsafe and persist history integrity marker, remove pending history integrity marker, server incarnation reset recorded and server incarnation changed while the sidecar was not running (PITR archiver), and the backup-stamp records, including backup-encrypt-upload's check backup stamp (Backup stamp).
• Removed line: verify.sh's BLOODRAVEN_VERIFY_REPLAY_COMPLETE (file, position, timestamp) is no longer printed; a verification's replay detail comes only from status.pointInTime (for example status.pointInTime.lastReplayedBinlog and status.pointInTime.newestReplayedCommitTime).
• Added Events: PITRArchiveUnsafeHistoryDetected, PITRMysqlConfRefused, PITRArchiveReissueRiskDetected, PITRDivergentHistoryExcluded and PITROnHistoryTransactionsExcluded (restored group or verification) and, on MysqlStandbyCluster, PITRArchiveRefused.
• Environment: restore and verification Jobs no longer render BLOODRAVEN_PITR_SITES, BLOODRAVEN_PITR_ALLOW_UNVERIFIED_CROSS_SITE or BLOODRAVEN_PITR_START_GTIDS; they render BLOODRAVEN_PITR_DESTINATION, BLOODRAVEN_PITR_ENCRYPTION_MODE, BLOODRAVEN_PITR_MODE and BLOODRAVEN_PITR_DUMP_META, BLOODRAVEN_PITR_STOP_DATETIME is always the canonical µs UTC form, and a dump-meta init container runs first. Sidecars also get BLOODRAVEN_FAILOVER_GROUP_UID and BLOODRAVEN_PITR_ARCHIVE_ID.
• Status fields: /archiver/status gains archive, divergentRows, quarantinedRows, promotionRecordedAt and historyIntegrity. The PITRArchiveReady condition gains the archive identity reasons and SidecarOutdated, and no longer previews spec.mysqlConf; the new PITRMysqlConfAccepted condition reports refused mysqlConf options. Manifest records gain kind (Reset for incarnation-reset records), probeInterval and readOnlyGtidExecuted. status.restore.pitr* is replaced by status.restore.provenance.pointInTime, and status.restoreInPlace.pitr* is removed (status.restoreInPlace.provenance.pointInTime stays unset); verifications add status.pointInTime.

v1.7.0: PITR archive encryption bindings (#203)

Additions only; no documented msg or field was renamed or removed.

• Added operator messages: pitr archive binding changed, pitr archive binding released, pitr render annotation ignored, pitr render deferred (PITR archive bindings).
• Added Job line and message: BLOODRAVEN_PITR_ARCHIVE_CHECK v=2 (its last key is destinationDigest, the hex SHA-256 of the normalized destination, which bounds the line under the 4096-byte termination message limit) and INFO pitr archive check from bloodraven pitr-archive-check.
• Added Events on the MysqlFailoverGroup: PITRArchiveBound, PITRArchiveBindingReleased, PITRArchiveEncryptionChangeRefused, PITRArchiveKeyChangeRefused, PITRArchiveBindingRefused, PITRArchiveKeySourceRemoved, PITRArchiveKeySnapshotRecreated, PITRArchiveKeyMaterialLost, PITRArchiveKeySnapshotReadFailed, PITRArchiveBindingReleaseRefused, PITRArchiveBindingReleaseRejected, PITRArchiveBindingLimitReached, BackupScheduleRefused; on a MysqlBackup, Normal PITRArchiveStampSkipped (the backup carries no archive stamp because the site renders disagree or none is readable). New condition PITRArchiveBindingReady; new MysqlBackup reasons ProfileReadOnly, PITRArchiveRolloutPending, DumpKeySnapshotConflict, PassphraseSecretMissing; new restore/verification tokens PITRArchiveBindingNotReady and PITRBackupDumpKeyMissing.
• Environment: sidecars get BLOODRAVEN_PITR_KEY_REVISION (the key snapshot name or plaintext) and no longer BLOODRAVEN_PITR_PROFILE_NAME; the retention query sends archive= instead of profile=.

Stability commitments

Pipeline integration tips

Filtering operational vs. controller-runtime

Most aggregators (Loki, Elasticsearch, Vector) let you split streams by JSON shape. A reliable predicate:

$.time && $.msg   // operational (slog)
$.ts && $.logger  // controller-runtime (zap)

Per-event alerts

Because every key event has a stable msg, pipeline alerts can be expressed as exact-match filters rather than fragile regexes. Examples for Loki:

# Failover started
{app="bloodraven"} | json | msg = "initiating failover"

# Failover failed (escalate)
{app="bloodraven"} | json | level = "ERROR" and msg = "failover failed"

# Divergence requires manual reclone
{app="bloodraven"} | json | msg = "divergence detected"

# Reclone triggered (track who/what asked for it via fg + recipient)
{app="bloodraven"} | json | msg = "starting bootstrap" and source = "reclone"

# Sidecar self-fenced — page on this
{app="bloodraven-sidecar"} | json | msg =~ "^SELF-FENCING:"

# Planned failover held automatic failover — page on this
{app="bloodraven"} | json | msg = "planned failover: automation held pending acknowledgement"

Correlating with metrics and Kubernetes Events

Several stable log events are mirrored by other observable signals — when one fires, the others fire too:

Prefer metrics for alert thresholds and Kubernetes Events for human notification routing; logs are richest for forensics and timeline reconstruction.

Useful structured fields to index

If your pipeline supports indexing specific fields, the high-value ones are:

• fg — partitions everything by failover group
• site (and oldPrimary / newPrimary / promotedSite / donor / recipient) — for per-site timelines
• level — for severity routing
• source — for bootstrap/reclone disambiguation
• error — full error string from the operator's error chain

PITR Job completion and failure metadata

PITR restore and verification Jobs run dump-meta, pitr-download, optionally decrypt-download, and then restore.py (see The restore Job). The init containers log JSON records. dump-meta records also carry subcommand="dump-meta".

Configuration and setup failures log, also with error: missing required env, invalid dump-meta config, resolve dump storage, init dump store and write dump metadata (dump-meta); invalid pitr-download config, invalid archive config and init archive store (pitr-download).

dump-meta and pitr-download write the same refusal, stable token first and bounded to about 3 KiB, to their termination messages, and the operator copies it into restore and verification status. The tokens and their order are in Restore refusals. A timestamp-mode PITRArchiveDivergentHistory names the transactions to exclude, up to 1 KiB, and pitr-download prints the whole set to its log as BLOODRAVEN_PITR_DIVERGENT_SET gtids=<set, up to 64 KiB>; it prints the same line on success when the plan excluded divergent transactions. coverage.json in the staging directory records the full plan, refusals included.

restore.py prints these text sentinels to its log:

A PITR Job's outcome comes from its main container's termination message, not its log. On success restore.py (through verify.sh on a verification) writes, as its last action:

BLOODRAVEN_PITR_VERDICT v=2 mode= stop= outcome= archive= encryptionMode= sourceUID= sourceNamespace= sourceName= segments= files= transactions= lastFile=<site>/<name> newest= divergent=<n> onHistoryExcluded=<n> executedSha256= sites=
BLOODRAVEN_PITR_RESULT v=1 executed=<set>
BLOODRAVEN_PITR_ON_HISTORY_EXCLUSIONS gtids=<set>

• Line 1, the verdict, is at most 1024 bytes. mode is timestamp or latest; stop is the µs UTC target (empty in latest mode); outcome is TargetCovered, Partial or ArchiveHead; archive and encryptionMode identify the archive and source* its source group; files counts the distinct files the segments read; transactions the replayed transactions; divergent and onHistoryExcluded are GTID counts; executedSha256 is the hex SHA-256 of the post-replay gtid_executed; sites lists at most eight staged sites plus a +N count. stop, source*, lastFile, newest and sites are percent-encoded.
• Line 2 carries the post-replay gtid_executed, or only executedSha256=<hex> when it is longer than 2 KiB.
• Line 3 is present only when the on-history exclusions are non-empty and short enough to fit; otherwise status records only their count.
• The message fits the main container's share of the kubelet's termination messages (12 KiB split among the pod's containers, at most 4 KiB each), which the operator renders as BLOODRAVEN_TERMINATION_MESSAGE_LIMIT (default 3072): line 3 is dropped first, then line 2 gives way to executedSha256=<hex>. No line is ever cut; verify.sh refuses PITRCoverageInvalid: restore.py's verdict is N bytes, over … rather than publish one that does not fit.

The operator accepts the verdict only from a Succeeded pod the Job owns, exit code 0, matching the rendered mode, target, encryption and source group, with a line 2 whose set hashes to executedSha256; anything else reports PITRCoverageInvalid. It fills pointInTime in status from it. restore.py and verify.sh write their own refusals there too (PITRCoverageInvalid: …, PITRArchiveIdentityMismatch: …, PITRExcludeIntersectsBackup: …, PITRNoArchivedReplay: …, PITRReplayMismatch: …, PITRReplayUnsupported: …, BLOODRAVEN_PITR_FAILED: …, SanityCheckFailed: …, SanityCheckTimeout: …). Other failures fall back to the log tail. The failure detail recorded in status is the earliest failing container's message. The served reason for BLOODRAVEN_PITR_FAILED is PITRReplayFailed; the message keeps the sentinel.

The Python restore Job's text sentinel BLOODRAVEN_RESTORE_COMPLETE carries only the source and target GTID and binlog coordinates, which the operator reads best-effort; the pitr* keys are gone. These Job messages are not in the Event reference contract above.

Artifact cleanup Job

The finalizer's cleanup Job runs bloodraven artifact-cleanup. It logs artifact cleanup complete (objects) or artifact cleanup failed (exitCode, error), with subcommand, backup, storageType and location on every record. These Job messages are best-effort, not part of the Event reference contract. The operator reads the outcome from the container's termination message instead: BLOODRAVEN_CLEANUP_COMPLETE objects=<n> on success, or BLOODRAVEN_CLEANUP_FAILED: <reason> on failure, with exit code 64 for a refusal or configuration error and 75 for a transient storage error. An abandoned (never-succeeded) backup's cleanup that finds no stamp but objects at the location deletes nothing, exits 0 with BLOODRAVEN_CLEANUP_SKIPPED: <reason> and logs WARN artifact cleanup skipped (reason), with the same common fields.