Reliability &
Availability

1. Availability target & SLA posture

We target 99.5 % availability per calendar month for the Dicomly gateway service. This target covers incoming DICOM C-STORE reception, mutual-TLS authentication, and egress delivery to customer HTTPS endpoints.

For self-serve accounts this is an operational availability target and carries no service credits. Contractual service level agreements with financial credits and scheduled operational review are part of an Enterprise agreement — tell us what your procurement process requires and we will put the commitment in writing.

We do not present our hosting provider's infrastructure SLA as our own. The target above measures the end-to-end path we operate: DICOM reception, authentication, and delivery to your endpoint.

2. Failure behaviour: predictable and safe

Dicomly is a stateless proxy that streams DICOM instances directly from the sender to your HTTPS endpoint. Nothing is persisted on disk or buffered in intermediate message queues.

When your destination server is unavailable, returns a 5xx error, or if network connectivity is interrupted during transfer, Dicomly immediately returns a DIMSE error to the sending modality or PACS.

The sending device then retries on its standard schedule (typically every 5 to 30 minutes for up to 24 hours), exactly as standard DICOM network protocols specify. Because Dicomly never holds or queues data, an outage on your side or ours results in temporary transfer delays — never silent data loss.

3. Where it runs

Dicomly runs in a single region: Frankfurt, Germany. All processing, all configuration data, and all backups stay inside the European Union. Nothing is replicated to a region outside the EU — that is a data protection commitment, and single-region operation is how we keep it absolute.

Recovery is therefore a rebuild rather than a failover: if the region or the node running the service is lost, the service is re-provisioned from infrastructure code and encrypted backups, against the recovery targets below.

That is safe for your imaging because of the design above. Dicomly holds no imaging data, so a rebuild has no study to restore — your senders still hold every study and deliver it on their next retry.

4. Recovery targets (RTO & RPO)

RPO for imaging data is not applicable: because Dicomly never stores, caches, or persists DICOM payloads or PHI, there is zero stored medical data at risk of loss during an infrastructure incident.

5. Maintenance & change management

Planned maintenance: Most software updates ship without interrupting service. Where an update does require an interruption, we give at least72 hours advance notice to registered account holders and schedule it in a low-traffic window. A maintenance window puts no data at risk: senders receive a DIMSE error, keep the study, and retry afterwards.

Security incident & breach notification: In the confirmed event of a security incident affecting customer metadata or credentials, Dicomly will notify affected customers without undue delay and within 24 hours of confirmation.

6. How you hear about an incident

An automated end-to-end check sends a real test transfer through the live path on a schedule and alerts us when it fails, so we do not learn about an outage from your support inbox.

• Notification: affected account contacts are emailed within 24 hours of a confirmed incident — sooner where the impact is ongoing.
• Written incident report on request, covering what happened, the impact window, and what changed as a result.
• Direct line during an incident: info@dicomly.ioreaches the people operating the service, not a ticket queue.

7. Where to look next

• Our security posture, certification status, and data residency are documented in our Security & Trust hub.
• For legal terms and commitments, see our Terms of Service and our Data Processing Agreement.
• Anything this page does not answer: info@dicomly.io. Security and procurement questionnaires go to security@dicomly.io and are answered in writing within 5 business days.