The infrastructure behind MCCSoft
MCCSoft runs its own products, and its clients' systems, on hardware it owns or administers directly. The public status board at status.mccsoft.io shows the result: ten components across three products, 90 days of history, and on 18 October 2026 no component below 99.98 percent uptime.
- 10components on the public board
- 90days of uptime history, a bar per day
- 99.98%lowest component uptime on 18 October 2026
A status board nobody edits by hand
The board lists ten components across MCCSoft, DankStocks and Homesly. Each shows its current state, a bar per day for 90 days and its past incidents. Anyone can subscribe by email; a notice goes out on a state change only. Every figure is derived from the monitoring system. No person types an uptime number.
Downtime is summed in seconds. A planned maintenance window counts in full, so the board does not flatter itself. Uptime is truncated, never rounded up: a component with any downtime shows at most 99.99 percent. Checks run every one to two minutes and the page is rewritten every minute. A planned restart is declared before it happens and recorded as planned.
A monitored fleet
Production sites run on a dedicated server in Virginia. Development, data, backups and monitoring run on four hypervisors in MCCSoft's own racks, about twenty virtual machines in all, plus a bare-metal GPU server for vision and language inference. Zabbix watches every host, and 17 of its triggers across eight hosts feed the status board.
Beside Zabbix, a Prometheus, Loki, Tempo and Pyroscope stack holds metrics, logs, traces and profiles, with Grafana in front. Every web request carries an id that appears in the web server log, the application log and the trace, so one slow request can be followed end to end. A trigger may fire only when a system is outside its normal range, and a new trigger is replayed against 30 days of history before it goes live.
Segmented networks
A firewall gateway splits the network into separate segments for the office, internal systems, client systems, data and voice. The client segment is default-deny with no internet egress: a host there reaches only the addresses it is allowed. An address that probes the production server for exploit paths is banned within a second of its third attempt. Failed database logins raise an alert.
Data that survives a host
Production databases run in a PostgreSQL cluster managed by Patroni: a leader and a streaming replica on separate physical hosts, reached through one floating address. A failover needs no application change.
Nightly snapshots of every server and database go to a backup server. Each morning that server pushes an encrypted copy offsite with restic. Once a month a full backup of every site, database, configuration and credential store is written to office storage, verified, and reported on in writing. Every production code tree is committed nightly to MCCSoft's own git server, so the exact code that runs can be diffed against development.
Self-hosted
Git, the password vault, the PBX, the remote-support relay, the monitoring, the dashboards and the status board are services MCCSoft runs itself. The marketing site's pages and the status board are served from MCCSoft's own servers; the site's static files ride an edge node MCCSoft also runs itself. No third party sits in the path. A daily security report ties every account, key and package change on every host to the login and the ticket that made it.
Want your systems run this way?
Tell us what you run. We will tell you what it takes to put it on a board like ours.
Contact MCCSoft