Transfer SLA

How it works

An SLA needs a start event and a done event. Done is a size or hash match, not a job start. A 15-minute SLA on a 50 GB file over a 20 Mbps link is impossible. Write SLAs the path can meet.

A partner SLA says the file is available by 02:30. The job finishes at 02:11 and the puller sees it at 02:18. Both timestamps are in the log. A target of 02:00 would have failed every night the file is over 8 GB on that link.

How it differs

An SLA is not a promise that the recipient opened the file. It is a promise about the transfer.

Measuring from email send includes human delay and blows the number.

Measure the system events.

On the ticket

• The practical close is a log line: time, actor, byte count, result.
• Without that line the transfer is a story.
• With it, the next person can see whether this door did what the ticket claimed.
• If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
• On a real ticket, write down the door, the byte count, and the clock.
• For sla, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
• A progress bar is not that record.
• A 200 response that arrives before the complete call is not that record.
• If a retry is allowed, say how many and whether it resumes.
• If a person must approve the send, name the person.
• Partners who receive sla files should match on hash or size before they import.
• A same-length corrupt file passes a size check and fails a hash.
• Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
• When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.