Availability
Eligible successful service behavior for defined requests or critical journeys.
Not a platform-wide claim from one endpoint.
Platform Reliability
Reliability you can measure. Recovery you can inspect.
Service definitions, measurement methods, change safety, dependencies, incident practice, recovery evidence — each with its scope, limitations, owner, and review date. This page explains how reliability is governed. It does not tell you whether the service is up right now.
Truth boundary
Platform Reliability is a governed explanation of how reliability is defined, measured, operated, recovered, reviewed, and evidenced. It is not a static uptime badge, and it never overrides the authoritative System Status source.
Source-of-truth boundary
Current operational state belongs on System Status.
This page owns
- Definitions and measurement methods
- Operational controls and change safety
- Recovery evidence and test results
- Limitations and correction history
System Status owns
- Current component state
- Active incidents and maintenance
- Subscriptions and timestamps
- Public operational history
If live status cannot be reached, we state that current status cannot be confirmed. A cached "operational" is never shown as current, and the absence of a visible incident feed never implies all systems are healthy.
Reliability Control Model
Seven Dimensions That Must Not Collapse Into One Number
A responding interface does not prove that records are correct, synchronized, or ready for payroll. These dimensions fail independently, so they are measured independently.
Performance
Latency, processing time, queue age, throughput, and load behavior within a defined scope.
Region, workload, and method always stated.
Job completion
Imports, exports, schedules, classifications, approvals, reports, and other asynchronous work.
A fast UI can sit above a stalled queue.
Data freshness
Time since source, processing, or synchronization event under a defined clock and scope.
Stale data is a reliability failure.
Integrity & durability
Completeness, uniqueness, consistency, lineage, persistence, verification, and correction.
No perfect-integrity guarantee is made.
Change safety
Validation, rollout, observation, rollback, and emergency-change evidence.
Most incidents begin as a change.
Recoverability
Backup, restore, failover, reconciliation, dependency, and human-response evidence.
Backup existence is not restore proof.
Why separate?
Collapsing these into a single uptime figure hides exactly the failures that affect workforce records most — a delayed export, a stale sync, a silent integrity gap.
Service Scope & Dependency Model
Define What Is Measured Before Showing Any Evidence
Six dependency classes, because "the platform was up" means very little if the failure sat in a customer-managed identity provider or a third-party integration.
| Dependency class | Examples | Whose responsibility |
|---|---|---|
| First-party service | Access, time capture, record processing, approvals, evidence, reporting | ZoikoTime |
| Zoiko product | Connected Zoiko products where a customer has enabled them | ZoikoTime, within the connected scope |
| Cloud / provider | Contracted infrastructure and platform services | Provider, under contract — not inherited assurance |
| Customer-managed | Identity provider, policy configuration, roles, retention settings | Your organization |
| Device & network | Endpoints, operating systems, browsers, corporate networks | Your organization |
| Third-party integration | Payroll, HR, ERP, and other connected systems | Shared, per connector scope |
Every scope record states
- Service, component, API, journey, or job identifier
- Environment, region, and data path
- Criticality, owner, and impact category
- Support path and current release state
And what is excluded
- Plans, versions, deployment models
- Providers, devices, operating systems
- Networks and customer configurations
Scope changes are versioned
A scope change creates a new version and triggers review of every metric and claim that depended on it. Old comparisons do not silently carry forward.
Measurement & Evidence Model
Nineteen Fields Before a Number Is Publishable
No metric exists without a denominator and an exclusion policy. The example below is a real indicator definition in a pre-publication state — which is why it carries no value.
IND-0004 · Export job completion rate
Measuring — quality under reviewPlain meaning
Share of eligible export jobs that completed successfully within the defined window.
Service scope
Reporting & exports · production
Event population
Export jobs submitted by authorized users
Numerator
Jobs reaching completed state
Denominator
Eligible jobs submitted in window
Unit
Percentage
Time window
Rolling 28 days
Timezone
UTC
Data source
Job execution records
Collection interval
5 minutes
Exclusions
Jobs cancelled by the requester; jobs blocked by customer configuration
Missing-data policy
Gap marked; window flagged as partial rather than interpolated
Quality checks
Source completeness, clock consistency, duplicate detection
Owner
Platform operations
Evidence status
Measuring
Last reviewed
28 Jun 2026
Next review
28 Sep 2026
Objective
None published — no approved target for this scope
Current value
Not published
Comparability
Definition v2; v1 results are not directly comparable
Why no value is shown: the indicator is instrumented and collecting, but data quality is still under review. Publishing a figure now would imply a maturity the evidence does not support. When it reaches Current, the value will appear here with its window, exclusions, and owner attached.
Eight reliability claim states
Definition draftInstrumentedMeasuringCurrentUnder reviewSupersededWithdrawnUnavailable
Internal thresholds are not public commitments
An alert condition exists to wake someone up. It is not an SLA, an objective, or a promise, and it is never converted into one by appearing on a marketing page. Objectives, error budgets, percentiles, and contractual commitments appear only where currently approved for the stated scope.
Performance, capacity & graceful degradation
Partially publishedObjective: behave predictably under load, and fail in a way users can understand.
- Controls
- Capacity planning inputs, safe operating ranges, queue and backlog visibility, rate limiting, load shedding, circuit breaking, concurrency control, timeout, retry, backpressure — where approved
- Degradation states
- Which functions are preserved, which are unavailable, what users are told, how data behaves, and the recovery route
- Evidence
- Synthetic and production evidence are kept distinct, never blended
Limitations: no "unlimited scale" claim, no guaranteed latency, and no benchmark without reproducible evidence stating region, environment, workload, dataset, method, date, and limitations. Internal thresholds that would increase security or abuse risk are not published.
Change safety & deployment reliability
CurrentObjective: make changes reversible, observed, and attributable — because most incidents begin as a change.
- Every change record
- Type, owner, scope, risk, dependencies, test evidence, approval, release window, rollout strategy, observation window, verification, rollback plan, communication, and final outcome
- Emergency change
- Named authority, stated reason, limited scope, post-change verification, retrospective review
- History preserved
- Failed, partially deployed, rolled back, superseded, and withdrawn changes all retain their history
Limitations: we do not claim every deployment is zero-downtime or automatically reversible — some changes are neither. Progressive delivery, canary, feature flags, and staged migration are described only where verified for the specific service. Rollback and forward-fix decisions remain human-authorized.
Detection, incident & maintenance practice
CurrentObjective: detect, own, communicate, recover, and review — while System Status remains the live source.
- Lifecycle
- Detection, triage, ownership, containment, mitigation, recovery verification, resolution, post-incident review
- Live communication
- System Status — this page never duplicates current state or maintains a competing history
- Human authority
- Authorized people assess impact, declare operational state, approve risky changes, decide recovery tradeoffs, and review conclusions
Limitations: no guaranteed notification or recovery time unless contractually approved. Post-incident review being pending does not imply a public report will be published.
Backup, restore, continuity & recovery
Under reviewObjective: prove that data can actually be brought back — not merely that copies exist.
- Backup record
- Source, protected object, environment, frequency, retention, encryption, location, access, integrity check, restore method, dependency, owner, last tested, result, limitation, next test
- Separated
- Restore · failover · rebuild · replay · reconciliation · manual recovery — these are different capabilities
- Recovery tests
- Planned scope, data sample, environment, result, gaps, corrective actions, owner, review date
Under review — do not rely on this as settled. RTO and RPO appear only where approved for a specific service, environment, contract, evidence period, and dependency context. None currently qualifies, so none is published. There is no "no data loss," instant-recovery, or universal regional-failover claim. Backup existence is not restore proof.
Data Integrity, Freshness & Reconciliation
Availability Does Not Prove Correctness
For workforce records this is the dimension that matters most. A service can be fully available while quietly serving a record that is incomplete, duplicated, out of order, or twelve hours stale.
Lineage controls — source identity, event order, duplicate detection, completeness, consistency, versioning, timestamps, reconciliation, correction, reprocessing, and downstream acknowledgment where supported.
Freshness definitions — the source event, the processing point, the clock, the expected interval, the grace window, missing-data treatment, and affected scope.
Visible exceptions — integrity exceptions stay visible and owned rather than being averaged away.
Recovery protection — issued or approved workforce records are never silently overwritten during a recovery.
Degraded mode — consequential downstream use pauses, or follows approved degraded-mode policy, when evidence is incomplete.
Two conclusions never drawn
Availability never proves payroll, legal, attendance, or time-record correctness. And missing or delayed data never produces an automatic misconduct or worker-risk conclusion — a data gap is an operational condition, not a finding about a person.
Where this connects
The reliability view of integrity and the product view of record correctness describe the same underlying concern from two directions.
Privacy-preserving observability
Reliability Telemetry Describes the Service, Not the Worker
No screenshots, keystroke content, URL history, application-name monitoring, or clipboard collection under any tier or configuration.
Permitted reliability signals
- Request counts, error classes, response time
- Job outcome, queue age, event lag
- Data-integrity check results
- Component, environment, region, provider, release version
- Synthetic-probe results and safe correlation identifiers
Never collected or derived
- Content capture or invasive device monitoring
- Worker productivity, diligence, or intent scoring
- Behavioral ranking or employment-risk inference
- Any claim of anonymity where re-identification remains possible in an authorized context
Worker identity is excluded or minimized unless necessary for a specific authorized support, security, or record-integrity investigation. Telemetry purpose, access, retention, aggregation, sampling, redaction, regional handling, sharing, incident use, and audit are all defined.
Reliability Evidence Directory
Definitions, Methods, Controls, Tests, and Limitations
DimensionService / componentEnvironmentRegionEvidence typeStatusAccess levelOwnerLast reviewed
Service scope & journey register
PublicComponents, journeys, environments, and dependency classes with owners.
- Owner
- Platform
- Reviewed
- 28 Jun 2026
- Status
- Current
Limitation: excludes customer-specific configuration.
Indicator definitions
PublicFull nineteen-field definitions, including exclusions and missing-data policy.
- Owner
- Platform operations
- Reviewed
- 28 Jun 2026
- Status
- Measuring
Definitions are public; values are not published while quality is under review.
Change safety controls
PublicValidation, rollout, observation, rollback, and emergency-change practice.
- Owner
- Engineering
- Reviewed
- 15 Jun 2026
- Status
- Current
Limitation: no zero-downtime or auto-reversibility claim.
Recovery test results
ControlledScope, sample, environment, result, gaps, corrective actions, and next test.
- Owner
- Platform
- Reviewed
- —
- Status
- Under review
Under review. No RTO or RPO published for any scope.
Integrity & reconciliation controls
ControlledLineage, duplicate detection, reconciliation, and correction pathways.
- Owner
- Platform
- Reviewed
- 01 Jul 2026
- Status
- Current
Access: governed request. Known failure modes included.
Availability results
ControlledMeasured availability by service, window, and eligible population.
- Owner
- Platform operations
- Reviewed
- —
- Status
- Unavailable
No current evidence supports publication. This does not imply future availability.
Withdrawn and superseded evidence is removed from current results and structured data, with a safe correction record retained. Search terms are never captured in analytics.
Shared Responsibility & Dependencies
Reliability Is Not Only Ours to Deliver
ZoikoTime
- Platform service operation and capacity
- Change safety and deployment control
- Detection, incident response, and communication
- Backup, restore, and recovery testing
- Integrity controls and reconciliation
- Evidence, limitations, and correction
Your organization
- Identity provider availability and configuration
- Endpoints, devices, and operating systems
- Corporate networks and egress rules
- Policy and retention configuration
- Connected systems you authorize
- Operational response on your side
Providers & integrations
- Contracted infrastructure within defined scope
- Third-party systems you connect
- Their state and limitations stay visible
- Their assurance is not inherited by us
Professional boundary. Reliability evidence does not guarantee payroll, employment, legal, compliance, tax, business-continuity, or financial outcomes. It describes how the platform is operated and what can be shown about it.
Controlled Access
Request Reliability Review
For recovery test results, integrity controls, and measured results where they exist. Access is determined by identity, purpose, and entitlement.
Direct Answers
Nine Reliability Questions
This page cannot tell you. Current component state, active incidents, and maintenance live on System Status, which is the authoritative source. If that source cannot be reached, it says current status cannot be confirmed rather than defaulting to operational.