Every artist who has shown interactive work has had the phone call. The piece is black. Nobody knows why. You are four hours away, the opening is tonight, and the person standing in front of it has no idea what a terminal is.
Making the work is the first job. Making it survive three months alone in a room is the second, and it’s the one nobody teaches.
1. It must start itself, from cold
Assume the power will be cut every night, by a cleaner, a timer, or the building. The piece must come back with nobody touching a keyboard.
- Enable auto-login. A login screen is a dead installation.
- Set the machine to power on when mains returns. It’s a BIOS/UEFI setting on PCs (“Restore on AC power loss”), and on a Mac it’s in Energy Saver / System Settings.
- Auto-start your application — Task Scheduler at logon on Windows, a Launch Agent on macOS, a systemd service or autostart entry on Linux.
- Add a delay of 20–30 seconds before your app launches, so the network, displays and USB devices have finished enumerating. Most start-up failures are a race condition between your software and hardware that isn’t ready yet.
Then test it properly: pull the plug at the wall, wait ten seconds, plug it back in, and walk away. If the piece isn’t running by itself in two minutes, it isn’t finished.
2. Kiosk mode and the hostile desktop
The operating system will try to ruin your show. Turn off, explicitly:
- Automatic updates and reboots (the single most common cause of a piece being replaced by a login screen)
- Screensaver, display sleep, system sleep, disk sleep
- Notifications, all of them
- Bluetooth pairing prompts, network prompts, “do you want to allow…” dialogs
- Mouse cursor — hide it, or park it offscreen
- Desktop wallpaper: set it to black, so a crash shows nothing rather than your desktop
Run the app fullscreen with no window chrome, and use kiosk mode where the OS offers it. On a Raspberry Pi running a web-based piece, a browser in kiosk mode with the cursor hidden is a well-trodden path.
3. A watchdog, because it will crash
Something will eventually fail — a leak, a driver, a cosmic ray. What matters is whether it recovers.
- Process-level: run your app under something that restarts it when it exits.
systemdwithRestart=alwayson Linux, a Launch Agent withKeepAliveon macOS, NSSM or a scheduled task on Windows. - Application-level: a crash isn’t the only failure. A piece can be running and frozen. Have the app write a timestamp to a file every few seconds, and a small separate script that kills and restarts it if that file goes stale.
- Hardware-level: for microcontrollers, enable the hardware watchdog timer. For a full computer in a hard-to-reach place, a USB watchdog dongle that physically power-cycles it is a cheap insurance policy.
4. Logging, so you can diagnose from a distance
When the call comes, you need to know what happened.
- Write a log file with timestamps: start-up, sensor connections, errors, restarts.
- Log counters once a minute — objects, memory, frame rate. Slow drift is invisible in the moment and obvious in a log.
- Rotate the logs so they don’t fill the disk. A full disk is its own failure mode.
- If the venue allows it, get remote access (Tailscale, a VPN, or even a daily emailed status line). Do this with the venue’s consent and their IT team’s knowledge, not around them.
5. The one-button reset
The person on site is not technical and shouldn’t have to be. Give them exactly one recovery action that fixes 95% of problems: usually a labelled power switch on an accessible extension lead.
Then write one page, laminated, taped inside the plinth or behind the screen:
- What the piece should look like when working
- “If it looks wrong: switch off at the red switch, wait 10 seconds, switch on. Wait 2 minutes.”
- Who to call, with a phone number
- What not to touch
Label every cable at both ends. Photograph the installed setup and tape the photo up next to the page. When someone unplugs something to hoover, the photo is what gets it back.
6. Soak test before it ships
Run the finished piece continuously for at least 72 hours in your studio, with logging on, and cut the power a few times at random. Nearly every failure that happens in a gallery is one that would have happened at home if it had been left running long enough.
Then, on site, run it through one full day-cycle before the opening — including whatever the building does to the lights and power overnight.