Service health and platform oversight¶
Draft. This page explains health, audit and the export/deletion lifecycle. The console is still being implemented. Complete data coverage, operational recovery, deployment and reader acceptance remain under review.
Zerohive gives authorized platform staff tools to investigate service problems and review recorded administrative actions. These help support explain an interruption, help operators locate an issue, and give managers a clearer account of what happened. They do not grant ordinary workspace members access to other organizations' information.
What the evidence means¶
| Evidence | What it helps explain | What it cannot establish on its own |
|---|---|---|
| Service health observation | Whether a configured service check returned a healthy, degraded, unhealthy or unknown result at a recorded time | That every user action works, or that an entire reporting period was free of interruption |
| Queue backlog | Recorded waiting work, work being handled and messages requiring investigation | That all waiting work has failed, or that no work exists when collection is missing |
| Workflow backlog | Incomplete billing, export and deletion workflows grouped by state | The outcome of every background task in the platform |
| Operational incident | A recorded error or integration problem and its available context | A complete event-by-event history or a confirmed root cause |
| Resource observation | A clue for operators investigating long-running database work | Complete coverage of slow actions, proven responsibility, automatic throttling or a billing measurement |
| Security signal | Selected recorded access/security events and administrative actions that help staff investigate | That every security event was collected, that a threat is confirmed, or that an incident has been resolved |
| Platform audit entry | A recorded administrative action, its actor and organization context when present, and accompanying details | That every possible action was recorded or that a later asynchronous process completed successfully |
Operational evidence and business impact answer different questions. A service may pass its health check while a particular request still fails. Conversely, a slow or unsuccessful check does not identify which users were affected. Support should connect the observation to the reported action and time before giving an explanation.
Resource monitoring currently has limits in identifying which organization caused an observation and in delivering alerts. Repeated observations can describe the same ongoing work. Treat them as investigation evidence; they do not establish that another organization was responsible, that its access was automatically restricted, or that the problem was resolved.
Health is an observation at a time¶
The health view selects the latest available observation for each matching service within a reporting window. Reading or refreshing that view retrieves stored observations; it does not itself run a new service check. Look at the observation time as well as the status.
Healthy means that the check reported a serving or healthy condition. Degraded or Unhealthy requires investigation. Unknown means that the available check did not establish a known result, for example because it timed out or could not be interpreted. Unknown must not be counted as healthy.
No matching observations can mean that the filters exclude them, the observations are too old, or collection did not produce records. It is not enough to conclude that everything is healthy. A longer reporting window may reveal an older observation, but does not make that observation current.
Counts and summaries also need a stated scope. A summary calculated from one page of results does not describe every service in the estate. A slowest-check value describes the observations considered; it is not an application response-time guarantee or an availability percentage.
Delayed work and incident signals¶
Waiting work can be normal during processing. The important questions are whether it is progressing, how long the relevant records have remained unchanged, and whether there is a reported failure. An elevated backlog is a prompt to investigate; the monitoring view does not itself retry, cancel or repair the work.
An empty monitoring result is different from a recorded zero. Collection can fail, omit an unconfigured source or lose its temporary observations after a restart. Staff should establish what was monitored and whether collection is still progressing before describing the workload as clear. A monitoring service can also retain its previous healthy result while a later read is unfinished; its health label alone does not establish fresh evidence.
An incident counter is not necessarily a count of failed customer requests. Some repeated observations update an existing incident record. Other records describe integration failures, and one underlying problem can contribute to more than one monitoring category. Do not add unrelated counters together or treat them as an invoice, a contractual service measure or a complete outage history.
Some incident updates retain details from earlier observations. Staff need to check those details against the reported problem before assigning responsibility; an update does not establish that every displayed detail is newly observed.
Understanding security oversight¶
Authorized staff can review selected security signals alongside relevant organization, actor and investigation context. Repeated events may appear as one grouped alert. An alert count therefore differs from an event count, and neither is automatically a count of affected people.
A signal marked for attention asks staff to investigate. It does not itself change access, assign responsibility or confirm that a problem has been resolved. Some signals describe expected administrative actions, such as an organization being suspended, which must be understood in context. General users should report the action, time and symptom through support rather than request access to another organization's security records.
An empty or quiet view is not proof that no concern exists. Staff must check the actual period, returned records and collection coverage. Managers and executives should ask for the confirmed business impact, evidence considered, responsible owner and next update, rather than treat a single counter as a security assurance.
Reviewing an administrative change¶
The platform audit view helps authorized staff answer who acted, which organization was involved, what action was recorded and when it was recorded. Some entries describe platform-wide work and therefore have no organization. System-initiated work can have no named actor.
The accompanying details depend on the action. An entry recording that work was requested is not proof that the work finished. Staff should check the owning process for the final outcome before telling a customer that a change, export or deletion is complete. Displayed actor and organization names can reflect their current records; they are not necessarily historical names captured at the time of the action.
Audit records belong to a restricted staff workflow. Support should communicate the relevant outcome and explanation without disclosing another organization's information or unnecessary personal details. This guide does not claim legal certification, universal logging coverage or a particular retention guarantee.
What each reader should do¶
For health or access problems, use the guidance below. For an export or organization closure, first read the data-handling sections that follow: preparing a copy, approving removal and confirming its outcome are separate responsibilities.
- Users and external participants: report the action you attempted, the workspace, the approximate time and any visible error. Use your organization's normal support route. Do not attempt to diagnose platform services.
- Workspace administrators: establish which users and tasks are affected, whether the problem repeats and whether access changed. Share that context with authorized support.
- Managers: distinguish a work delay from a completed failure. Identify the business deadline and affected process so support can assess impact.
- Executives: ask for the affected scope, evidence period, confirmed impact, current owner and remaining uncertainty. A green health card alone is insufficient evidence of end-to-end availability.
- Support: connect the report to current evidence, retain useful references and explain the next responsible team. Avoid promising recovery or completion before it is confirmed.
The console includes Operations → Service Health, Backlogs, Errors & Failures, Security Signals and Audit Log. The current implementation applies supported filters and paging; its summaries describe returned records, not proof of complete platform coverage. A failed read and a successful empty result have different meanings. These staff tools are not publicly available self-service pages. General readers should use the support route above and the workspace access guide when the issue concerns paused access.
Requesting an organization export¶
An export prepares an archive of participating services' organization data. Authorized platform support starts the job; ordinary members do not gain access to a whole organization archive. Starting an export does not itself pause access or delete the organization's data. Services contribute separately, so the word snapshot does not establish one synchronized capture of all activity across the platform.
Agree the purpose, organization, responsible recipient and required scope with your administrator and support before requesting a copy. The job first collects contributions, then packages the archive. A request being accepted means processing has begun; it does not mean the archive is ready. Staff must check the explicit outcome, any failure and the expiry time.
The current implementation sets expiry seven days after the export job is created. Processing consumes part of that period. It does not start a fresh seven-day period when the archive becomes ready. Arrange authorized collection promptly; the archive is not a permanent backup or an established restore facility. Complete coverage of every service, attachment and external system is still being reconciled, so agree the required contents and verify the resulting archive before relying on it.
An eligible recipient must use an authenticated session for the same organization. The download check permits the initiating user or a currently active organization administrator, subject to that session and the archive being ready and unexpired. A platform role or an email notice alone does not satisfy all of those checks. The generated download link lasts no longer than ten minutes, and can expire sooner if the archive's deadline is closer. Treat that link and any downloaded copy as sensitive organization data.
The system requests a ready notification for the initiating user's recorded email and active organization administrators, avoiding duplicate email addresses. A job's ready status does not prove an email was delivered or that a recipient downloaded it. If a link expires, an eligible recipient may obtain another while the archive remains eligible. After archive expiry, ask support to review whether a fresh export is appropriate.
When an archive link does not deliver a file¶
Receiving a temporary link means the system issued access to the archive after checking eligibility. It does not prove the file was transferred, that the storage service is reachable or that the archive contains everything required for your purpose. A link may also expire while you are trying to use it.
If a download fails, retain the export reference, time and visible error for authorized support. The responsible team should confirm the archive's state and expiry before arranging another eligible attempt or a new export. Do not treat a failed download as a request to delete data or restart the entire closure process. Keep temporary links and downloaded copies within the organization's approved handling process.
Understanding the contents and limits¶
Participating services declare work records such as requests and approvals, organization and staff information, correspondence, records and cases, projects, collaboration, activity history, analytics and governed AI data. The actual archive follows each service's declared coverage. A record describing a document, meeting artifact or mailbox connection is not necessarily a copy of the file, recording or mailbox itself. Governed knowledge manuals have a separate path for including verified document content.
Platform account administration, billing and metering are outside the standard export participant list. External-work records and shared enterprise relationships also need separate scope review. An organization export should therefore be checked against the business need; it must not be presented as a complete account of every record held by Zerohive and its external providers.
Deletion has similarly defined coverage. Some services remove local records; particular document and AI paths also remove known stored artifacts. A service reporting that it retained zero records does not establish that no backup, earlier archive, provider copy or shared record remains elsewhere. Ask support to identify those separately before treating closure as a broader erasure assurance.
Activity history receives another policy check during processing. If a legal hold becomes active after confirmation, that part of the deletion remains unresolved. Removing the hold does not itself confirm that processing has resumed. Support must establish the current job outcome and the approved recovery action.
Closing an organization through deletion¶
Deletion is a separate process from temporarily pausing access. It starts with a new export snapshot and waits for an administrator's confirmation before dispatching service deletion. Preparing the request and confirming irreversible work are distinct actions with different permissions.
The current checked-in setup requires a seven-day review period after the deletion job records its snapshot as ready. Confirmation also requires a verifiable activity-history retention policy and no active legal hold on that history. A screen offering confirmation is not proof that these checks will pass. Follow the organization's approval process; the implementation does not enforce that the person confirming must be different from the person who started the request.
The export deadline and deletion review period use different starting times. With the checked-in seven-day settings, the export can already be expired by the time deletion becomes eligible for confirmation. Do not assume the snapshot will still be downloadable then, that it is preserved indefinitely, or that the product can restore the organization from it. This timing needs operational resolution before relying on the process for closure.
An authorized administrator can cancel a deletion while it is preparing its snapshot or waiting for confirmation. Cancellation is unavailable after service deletion begins. Cancelling the deletion request does not establish that the associated export was also cancelled or removed. Export cancellation likewise does not establish that every worker stopped immediately or that no temporary or uploaded data exists.
After confirmation, participating services report their deletion work and the platform performs finalization. A completed job records that this workflow reached its final state. It is not proof that every record in every external identity system, backup, retained audit store or storage location has been erased. The inspected implementation still has an unfinished identity-system removal step. Complete deletion scope and retained-data handling must be reconciled before support issues a broader erasure assurance.
Responsibilities during export or closure¶
| Reader | Responsibility |
|---|---|
| Organization administrator | Verify the organization and requested scope, arrange an eligible recipient, review the archive before its deadline and coordinate closure approval. |
| Manager | Identify active work and business dependencies that closure would interrupt; coordinate the timing with the organization owner. |
| Executive or accountable owner | Approve the business decision through the organization's process and ask for evidence of scope, completion, retained data and unresolved exclusions. A status card alone is insufficient. |
| User or external participant | Follow your administrator's instructions about ongoing work and any approved copies. A closure request does not grant wider export or deletion permission. |
| Support | Confirm the actual job outcome and remaining limits before communicating success. Route incomplete, blocked or ambiguous outcomes to the responsible operator. |
The intended staff journey starts in a tenant's Tenant Data Operations panel and continues through Compliance → Export Jobs or Deletion Jobs. Current job views preserve recorded states and check the selected job before actions, but mutation responses and uncertain outcomes still need care. These guides describe the intended journey and verified safeguards, not a claim that production closure is ready. Do not repeat an irreversible action simply because a response was unclear: staff should read the job's current state first.