How the KriptoNyx chain and the services around it are monitored, and how changes and patches are put live. The status page shows the result of this monitoring as it runs.
Monitoring
The node, and whether the chain is moving
- The node service is running and fully synced.
- A new block has been produced recently — the chain makes one about every two seconds, and a gap of a minute is treated as a failure.
- The chain height is advancing between checks. A stalled node can still answer requests; only the height standing still reveals it.
- The node has peers.
The public endpoint wallets and apps depend on
- The public RPC answers and returns a block height.
- It identifies itself as chain 3009 — an endpoint serving the wrong chain is worse than one that is down, because a wallet cannot tell the difference.
- It is no more than 10 blocks behind the node, so it is not serving stale state.
- It responds within two seconds.
The host, the processes and the certificates
- Disk, memory and load on the host, against set limits.
- Every application process that serves a public site is running.
- Every site's TLS certificate is read directly and flagged at 14 days from expiry — independently of the automatic renewal, so a renewal that silently fails is caught.
Each public site
The explorer, staking, DEX, ICO, faucet, bridge and API are each fetched and checked against the response they are meant to give, not simply for a successful reply.
What counts as down
- All 39 checks run every 60 seconds.
- A check is marked down after failing three consecutive times — a single failed request is noise, three minutes of failures is an outage.
- A down check opens an incident, shown on the status page; one healthy check closes it. Each outage is reported once, not on every check.
- A probe that cannot reach a conclusion is recorded as unknown and never on its own reports anything as down.
What is kept
- Every check is recorded, not only failures, so the record shows what was healthy as well as what was not. The incident history on the status page is rebuilt from it.
- Kept for 30 days, rotated daily.
- Node, application and web-server logs are kept separately by each service.
Patching and deployment
Every change, to any component, follows the same five steps.
- Change the component's source.
- Build it.
- Publish it, using that component's documented deploy procedure.
- Verify — run a full health sweep. All 39 checks must pass before the change is considered live.
- Roll back to the previous release if any check fails, then investigate.
By component
Chain node
The previous release is kept before an upgrade. The new one is installed and the node restarted; it must return to fully synced with the height advancing. Rollback restores the previous release. Upgrades that change consensus are coordinated with the other validators at an agreed height, separately from this procedure.
Web applications — explorer, staking, DEX, ICO, faucet
Built from source and published by each application's own deploy procedure, then verified. For the DEX, the previous build is kept alongside so it can be restored immediately, because a failed build would otherwise take the live site down with it.
Backend services — API, bridge, accounts
Updated from source and restarted under the process manager, then verified.
TLS certificates
Renewed automatically, and checked independently by the monitoring above.
Cadence
Operating system — security updates applied, then a full health sweep.
Dependencies — security advisories reviewed at each change to a component.
Node — releases applied as published, by the procedure above.
Certificates — automatic renewal, independently monitored.
This page describes the process; the live results are on the status page. The detailed operational runbook, including hosts, commands and rollback steps for each component, is maintained separately and available on request.