Service 05 · Monitoring and support, day and night
Managed services for your servers and applications, from Strasbourg, day and night.
Continuous monitoring, security patches, backups that are checked and a person on call for incidents. When something breaks at night, we are the ones who get woken up.
First conversation free.
What managed services cover, and what they do not
We operate servers and applications: yours, or the ones we have written. Not office computers, not printers, not office software. The contractual framework is in the annex to our terms of sale on keeping systems in working order.
- 01
Critical applications. Downtime is expensive, in revenue or in reputation. You need availability that is measured, not hoped for.
- 02
Teams with no on-call support. You have nobody at night or at weekends. We keep watch, and your developers stay on the product.
- 03
A requirement for continuity. You have to prove you have a recovery plan, backups and restoration times. We put them in place, test them, and give you the measurements.
Who it is not for
Managing a fleet of workstations, office software licences or company e-mail: an IT equipment support provider is better placed for that.
“Reliable” can be measured.
The details, on the blog: what “reliable” really means.
An application that matters should not depend on luck. We operate it continuously: probes that test it once a minute, security patches tracked machine by machine, logs that are centralised and reviewed, and a person on call for incidents. When something goes wrong, someone answers, not an answering machine.
Together we set concrete objectives: the acceptable recovery time, the tolerated data loss, the response time and then the restoration time according to criticality, and a recovery plan that we test instead of promising it.
Every month, a report tells you what happened, what we did and what is still to be dealt with. The figures on this page come from it: they are our instruments, not our sales arguments.
Covered by operations
- Continuous monitoring, one measurement per minute
- Security patches tracked on every machine
- Backups every night, checked automatically
- Logs centralised and kept for investigation
- A person on call for critical incidents
- Monthly report: incidents, availability, actions
Three levels, one objective
Three levels, detailed in the quote. You choose the one that matches how critical each application is; the monthly report is included in all three.
- 01
Essential: monitoring, backups and patches during working hours. The foundation: nothing goes unnoticed.
- 02
Standard: monitoring day and night, alerts that wake someone up, committed response and restoration times.
- 03
Premium: reinforced on-call support, a tested recovery plan, short recovery times and priority for interventions.
Who answers at night
An alert wakes one of the two of us, who knows your application because he wrote it or hosts it. Not a call centre, not a ticket waiting for the morning.
Our measurements, in detail
Each figure comes with its instrument, its measurement window and its method of calculation. Enough to repeat the measurement, or to prove us wrong. The case studies on our infrastructure and our delivery pipeline describe what produces them.
- Your applicationruns on our servers, which we administer ourselves
- Entry pointtraffic is encrypted, everything else is blocked
- Segmented networkno machine can be reached directly from outside
- Servers in Francethree separate data centres, in Strasbourg, Roubaix and Gravelines
- Encrypted backupa copy every night, checked, on a second site
- Monitoring day and nightwe see the outage before you do, and we get woken up
| Measurement | Value | Instrument | Method | Date |
|---|---|---|---|---|
| Average availability of the websites we host | 99.89% | Internal Uptime Kuma monitoring (HTTP probes, one measurement per minute) | Average of the 9 HTTP probes on public websites hosted on dedicated machines, over the rolling 30 days ending on 4 September 2026 at 23:45 UTC. Calculation: time in the “up” state divided by the time observed, per probe, then an unweighted average. | 5 Sep 2026 |
| Availability of our own website, www.sanfytech.com | 99.91% | Internal Uptime Kuma monitoring (HTTP probe, one measurement per minute) | Public HTTP probe on www.sanfytech.com, rolling 30 days ending on 4 September 2026 at 23:45 UTC: 43,143 “up” readings against 37 “down” readings. | 5 Sep 2026 |
| Average availability over 90 days of the websites monitored for at least 90 days | 99.74% | Internal Uptime Kuma monitoring (HTTP probes, one measurement per minute) | Average of the 5 website probes whose history genuinely covers 90 days, rolling window ending on 4 September 2026 at 23:45 UTC. Websites put into service more recently are excluded: we do not fill out a short window with an extrapolation. | 5 Sep 2026 |
| Active monitoring probes across our machines | 58 | Internal Uptime Kuma monitoring | Inventory of monitors on 5 September 2026: 62 active monitors, 4 of which are simply display groupings, giving 58 real probes (HTTP, ping, TCP port and backup heartbeats). | 5 Sep 2026 |
| Machines whose logs are sent to the SIEM in real time | 40 | Wazuh SIEM (internal administration console) | Count of agents registered with the Wazuh manager on 5 September 2026: 40 agents, all in the “active” state, that is 39 administered machines plus the SIEM server itself. | 5 Sep 2026 |
| Machines tracked for the application of security patches | 39 | PatchMon patch manager (internal console) | Inventory of registered hosts on 5 September 2026: 39 hosts, all in the “active” state and all having sent a report within the previous 24 hours. | 5 Sep 2026 |
| Backup frequency for hosted machines | 1 per day | Backup scheduler of the virtualisation cluster | Daily job at 20:00 UTC (10 pm Paris time) covering all guests of the cluster, in snapshot mode. Three machines with a particular profile have a dedicated weekly job. Reading of the configuration in force on 5 September 2026. | 5 Sep 2026 |
| Backups completed successfully over the last seven days | 322 out of 322 | Dedicated backup server (Proxmox Backup Server) | Task log of the backup server between 28 August 2026 at 23:48 UTC and 4 September 2026 at 23:48 UTC: 322 backup tasks, 322 completed without error, none failed. | 5 Sep 2026 |
| Backup integrity checks over the last seven days | 7 out of 7 | Dedicated backup server (Proxmox Backup Server) | A backup that is never read back is not a backup. Daily verification job at 04:00 UTC on snapshots that have never been checked, supplemented by a full monthly re-read beyond 30 days. Over the window from 28 August 2026 to 4 September 2026: 7 verifications, all without error. | 5 Sep 2026 |
| Restore depth kept for hosted machines | 7 daily, 2 weekly, 1 monthly | Dedicated backup server (Proxmox Backup Server) | Pruning rules in force on 5 September 2026 on the storage area for hosted machines: 7 daily, 2 weekly and 1 monthly backups kept. Infrastructure machines outside the cluster go up to 30 daily, 12 weekly and 12 monthly backups. | 5 Sep 2026 |
| Separate sites holding a copy of the backups | 2 sites | Dedicated backup server and its mirror outside the hosting provider | Primary copy on a dedicated backup server located in a fourth data centre, in Germany; second copy made every night (05:30 and 06:00 UTC) to a mirror located outside the hosting provider, in France. The mirror pulls the data: the primary server has no access to it. Status checked on 5 September 2026, 1.4 TB replicated. | 5 Sep 2026 |
| Backup encryption | Encrypted at source | Storage configuration of the virtualisation cluster | Data is encrypted on the original machine before being sent: the backup server only receives encrypted blocks. Presence of an encryption key declared on the storage area for hosted machines, checked on 5 September 2026 (fingerprint recorded, key never exposed). | 5 Sep 2026 |
| OVHcloud data centres housing our hypervisors | 3 in France | OVHcloud public API (dedicated server records) | “datacenter” field of the three dedicated servers read on 5 September 2026: sbg3 (Strasbourg), rbx8 (Roubaix), gra2 (Gravelines). Three separate sites, all in France. | 5 Sep 2026 |
| Data centre housing the backup server | 1 in Germany | OVHcloud public API (dedicated backup server record) | “datacenter” field of the backup server read on 5 September 2026: lim3 (Limburg, Germany). A site separate from the hypervisors, with the data kept within the European Union. | 5 Sep 2026 |
| Virtual machines and containers hosted on the cluster | 37 | Virtualisation cluster (guest inventory) | Count on 5 September 2026: 37 active guests, 29 containers and 8 virtual machines, spread across the three hypervisors. | 5 Sep 2026 |
Average availability of the websites we host99.89%
- Instrument
- Internal Uptime Kuma monitoring (HTTP probes, one measurement per minute)
- Method
- Average of the 9 HTTP probes on public websites hosted on dedicated machines, over the rolling 30 days ending on 4 September 2026 at 23:45 UTC. Calculation: time in the “up” state divided by the time observed, per probe, then an unweighted average.
- Date
- 5 September 2026
Availability of our own website, www.sanfytech.com99.91%
- Instrument
- Internal Uptime Kuma monitoring (HTTP probe, one measurement per minute)
- Method
- Public HTTP probe on www.sanfytech.com, rolling 30 days ending on 4 September 2026 at 23:45 UTC: 43,143 “up” readings against 37 “down” readings.
- Date
- 5 September 2026
Average availability over 90 days of the websites monitored for at least 90 days99.74%
- Instrument
- Internal Uptime Kuma monitoring (HTTP probes, one measurement per minute)
- Method
- Average of the 5 website probes whose history genuinely covers 90 days, rolling window ending on 4 September 2026 at 23:45 UTC. Websites put into service more recently are excluded: we do not fill out a short window with an extrapolation.
- Date
- 5 September 2026
Active monitoring probes across our machines58
- Instrument
- Internal Uptime Kuma monitoring
- Method
- Inventory of monitors on 5 September 2026: 62 active monitors, 4 of which are simply display groupings, giving 58 real probes (HTTP, ping, TCP port and backup heartbeats).
- Date
- 5 September 2026
Machines whose logs are sent to the SIEM in real time40
- Instrument
- Wazuh SIEM (internal administration console)
- Method
- Count of agents registered with the Wazuh manager on 5 September 2026: 40 agents, all in the “active” state, that is 39 administered machines plus the SIEM server itself.
- Date
- 5 September 2026
Machines tracked for the application of security patches39
- Instrument
- PatchMon patch manager (internal console)
- Method
- Inventory of registered hosts on 5 September 2026: 39 hosts, all in the “active” state and all having sent a report within the previous 24 hours.
- Date
- 5 September 2026
Backup frequency for hosted machines1 per day
- Instrument
- Backup scheduler of the virtualisation cluster
- Method
- Daily job at 20:00 UTC (10 pm Paris time) covering all guests of the cluster, in snapshot mode. Three machines with a particular profile have a dedicated weekly job. Reading of the configuration in force on 5 September 2026.
- Date
- 5 September 2026
Backups completed successfully over the last seven days322 out of 322
- Instrument
- Dedicated backup server (Proxmox Backup Server)
- Method
- Task log of the backup server between 28 August 2026 at 23:48 UTC and 4 September 2026 at 23:48 UTC: 322 backup tasks, 322 completed without error, none failed.
- Date
- 5 September 2026
Backup integrity checks over the last seven days7 out of 7
- Instrument
- Dedicated backup server (Proxmox Backup Server)
- Method
- A backup that is never read back is not a backup. Daily verification job at 04:00 UTC on snapshots that have never been checked, supplemented by a full monthly re-read beyond 30 days. Over the window from 28 August 2026 to 4 September 2026: 7 verifications, all without error.
- Date
- 5 September 2026
Restore depth kept for hosted machines7 daily, 2 weekly, 1 monthly
- Instrument
- Dedicated backup server (Proxmox Backup Server)
- Method
- Pruning rules in force on 5 September 2026 on the storage area for hosted machines: 7 daily, 2 weekly and 1 monthly backups kept. Infrastructure machines outside the cluster go up to 30 daily, 12 weekly and 12 monthly backups.
- Date
- 5 September 2026
Separate sites holding a copy of the backups2 sites
- Instrument
- Dedicated backup server and its mirror outside the hosting provider
- Method
- Primary copy on a dedicated backup server located in a fourth data centre, in Germany; second copy made every night (05:30 and 06:00 UTC) to a mirror located outside the hosting provider, in France. The mirror pulls the data: the primary server has no access to it. Status checked on 5 September 2026, 1.4 TB replicated.
- Date
- 5 September 2026
Backup encryptionEncrypted at source
- Instrument
- Storage configuration of the virtualisation cluster
- Method
- Data is encrypted on the original machine before being sent: the backup server only receives encrypted blocks. Presence of an encryption key declared on the storage area for hosted machines, checked on 5 September 2026 (fingerprint recorded, key never exposed).
- Date
- 5 September 2026
OVHcloud data centres housing our hypervisors3 in France
- Instrument
- OVHcloud public API (dedicated server records)
- Method
- “datacenter” field of the three dedicated servers read on 5 September 2026: sbg3 (Strasbourg), rbx8 (Roubaix), gra2 (Gravelines). Three separate sites, all in France.
- Date
- 5 September 2026
Data centre housing the backup server1 in Germany
- Instrument
- OVHcloud public API (dedicated backup server record)
- Method
- “datacenter” field of the backup server read on 5 September 2026: lim3 (Limburg, Germany). A site separate from the hypervisors, with the data kept within the European Union.
- Date
- 5 September 2026
Virtual machines and containers hosted on the cluster37
- Instrument
- Virtualisation cluster (guest inventory)
- Method
- Count on 5 September 2026: 37 active guests, 29 containers and 8 virtual machines, spread across the three hypervisors.
- Date
- 5 September 2026
Measurements taken on 5 September 2026.
Before the next incident
To prepare for it, on the blog: what a disaster recovery plan really contains.
What happens when an alert goes off at three in the morning?
The probe alerts us, one of us logs in, restores the service and writes to you about what happened. Depending on the level chosen, the response time is committed in the contract.
What does the monthly report contain?
The month's incidents, the availability measured by the probes, the patches applied, the backups checked and what we recommend. The same figures as the ones published here.
How do I choose the level?
By criticality: what an hour of downtime costs, and at what time of day. An internal application used during the day often falls under Essential; a site that takes payments at night, under Standard or Premium. We decide it with you during scoping.
Timelines, quotes, code ownership, end of contract: the answers are in the FAQ.
Quoted per project. Price ranges are published on the pricing page, along with what makes a budget vary.
Before the next incident
Who answers when your application goes down?
Describe what you run today. We will tell you what we would monitor, what we would take over, and at what price.
Reply within 24 working hours, from one of the two founders.