When a script becomes infrastructure
Three signs a script has become a system - and needs to be treated as one.
The transition from script to system is rarely declared. It happens when other things start depending on the script's output. The signs are recognisable if you know to look for them.
Signal 1
Other workflows depend on its output
The script was written to solve one person's problem. At some point, someone else started depending on its output - another workflow reads the file it produces, a dashboard pulls from the table it writes, a notification goes out based on its result. The script now has dependents. If it fails silently, those dependents fail too, often in ways that are harder to diagnose because the failure appears to originate from them rather than from the script.
Once a script has dependents, it needs error handling, monitoring, and documentation. Not because the script is more complex, but because the consequences of its failure are no longer isolated.
Signal 2
The person who wrote it is the only one who can change it
If modifying the script requires the original author to be available, the script has a single point of failure that is a person rather than a piece of technology. This is the most dangerous form of infrastructure dependency because it is invisible in normal operation and catastrophic when it matters.
Any script that cannot be understood and safely modified by a capable person who was not involved in writing it needs documentation before it is infrastructure. Not a code walkthrough - an explanation of what it does, what it depends on, and what to do when it produces unexpected results.
Signal 3
Its failure would require immediate action
If the script stopped running tomorrow and nobody noticed for a week, it is a convenience tool. If its failure would require immediate diagnosis and resolution, it is infrastructure. The urgency of a failure reveals the actual operational importance of the thing that failed.
Scripts that would require immediate action when they fail should have monitoring that provides immediate notification. Not because monitoring is inherently required for scripts, but because the operational importance demands it.
When not to upgrade
Sometimes a script should stay a script.
Not every script that runs repeatedly needs to become a system. A script that one person uses occasionally, that has no dependents, and that would cause no operational impact if it stopped working does not need error handling, monitoring, or documentation. Adding those things would be engineering overhead with no operational benefit.
The question to ask is not "how long has this script been running?" but "what would happen if it stopped?" The answer determines whether investment in making it a proper system is justified or whether the investment is better spent elsewhere.
The upgrade path
Turning a working script into a maintainable system takes four additions - not a rewrite.
The mistake is thinking the upgrade from script to system requires starting over. In most cases, the logic is sound and the code works. What it needs is the operational layer that makes it trustworthy for others to depend on.
The upgrade is not a rewrite
What to add without rewriting
Error handling with explicit failure modes: what happens when the input data is missing, when a dependency is unavailable, when the output cannot be written. Each failure should produce a specific, interpretable log entry.
Monitoring that alerts when the script does not run or produces output outside normal parameters. Not complex analytics - a notification when something that should have happened did not.
Plain-language documentation: what the script does, what data it depends on, what it produces, and what to do when it fails. One page is usually enough.
A test for the most likely failure: a way to confirm the script is working correctly that does not require running the full production workflow. This is the test the next person runs when they are not sure if a change broke something.
A script becomes infrastructure when other things depend on it
The moment another workflow reads the script's output, the script's failure is no longer isolated. It has dependents. That changes the level of care it requires, not the code, but the operational layer around it.
The upgrade is four additions, not a rewrite
Error handling with explicit failure modes. Monitoring that alerts when expected output does not appear. Plain-language documentation of what it does and what to do when it fails. A single test for the most likely failure. None of these require rewriting the core logic.
Documentation serves the next person, not the original author
The original author already knows what the script does. Documentation exists so a capable person who was not there when it was written can understand, operate, and safely modify it. If writing the documentation feels unnecessary, the script probably does not have dependents yet.
The test for infrastructure status is the failure question
The failure question settles it: would anyone have to act immediately if this stopped running? If yes, it is infrastructure, however it started life, however long it has run.
Common questions
Questions about scripts and systems
Ask two questions: would its failure require immediate action, and do other workflows depend on its output? If either answer is yes, it is infrastructure. The other tell is the bus factor question, if the person who wrote it left tomorrow, could someone else diagnose a failure without calling them? If not, it is infrastructure without the operational layer that infrastructure needs.
Almost never. The core logic is usually sound. What a working script needs to become reliable infrastructure is an operational layer: error handling that produces interpretable failures, monitoring that alerts when expected output does not appear, documentation that explains what it does and what to do when it fails, and a test for the most likely failure. These additions take hours, not weeks.
When it has no dependents, its failure would cause no operational impact, and only one person uses it. Treating a convenience tool as infrastructure adds overhead with no benefit. The upgrade is only warranted when the script's operational importance justifies it, and that importance is revealed by the failure question, not by how long the script has been running.
Bend, do not break. A script that hits a missing file, a down API, or an unreachable database should degrade to a reduced but working mode rather than crashing or silently dropping the run. Retry a transient failure with backoff, hold the work and alert on an extended one, and fall back to read-only if it can still be useful without writing. The failure that needs a human should be loud and logged; the one that can wait should recover on its own. Dropping the work without a trace is the option infrastructure cannot take.
