Working offline at the venue
Internet connections can be flaky at remote event locations, and especially at festivals or large public gatherings where everyone is on their phone.
1pm crew links are designed around this fact: the run of show is meant to keep working when the network drops, and quietly catch up when it comes back. This article covers what works offline, what doesn't, and how to set up before an event so crew aren't caught out.
The short version: open the crew link once on Wi-Fi before the event, and the run sheet will still load and be tappable on the day even if the network's gone. Items the crew member taps while offline get queued and synced automatically when the connection returns. No special "offline mode" toggle, no manual sync button.
Where offline support applies
Offline behaviour is built into the per-crew share link at /v/{token}. That's the link you generate per crew member from the Crew panel on the planner page, and the one you email or copy to each supplier individually.
The public shareable runsheet at /r/{token} is a separate read-only view designed for QR-code distribution at the venue. It doesn't carry the offline machinery: there's nothing for an anonymous viewer to write back to the server, and the page is meant to be a quick "what's happening now" reference, not a tool that a single person uses heads-down all day.
For crew who are actively working the event and need to mark items off, the per-crew link is the right one to share. The public link is for everyone else.
What works without Wi-Fi
After at least one online visit to their crew link, a crew member can:
Reload the page. The full run sheet (timeline, briefing, notes, files list, attachments) renders from the device's local cache. Times, titles, locations, the lot.
Tap Start, Mark finished, Done, or Undo on any of their items. The action queues locally and the UI updates immediately, so the page feels just as responsive as when online.
Switch between All and Mine views. Both URLs are cached separately so the toggle keeps working.
Read attached notes and details. Anything that was on the page when they last loaded online is still readable offline.
Switch tabs and come back. The page survives a tab swap or a phone lock without losing state.
What doesn't work without Wi-Fi
A few things genuinely need a network round-trip, so they pause until the connection returns:
Live updates from the planner. If you push a change from the planner while a crew member is offline, they won't see it until they're back online. The cached version they're looking at is the last one their device synced.
File downloads. Attachments and uploaded files need to fetch from the server. Tapping a file link while offline shows the browser's standard "can't reach this page" until the network comes back.
External link attachments. Anything that links out to Google Drive, Dropbox, or a vendor portal needs that vendor's network too. Beyond 1pm's control.
Pulling a fresh share link. Generating a new link, sending an email invite, or rotating a token all need the server.
How the connection status shows
When a crew member is offline, a small pill at the top of their share link changes colour and reads "Offline". When they come back online, the pill goes back to its normal connected state.
If they've tapped any actions while offline, a snackbar at the bottom of the screen shows the sync state:
While offline with queued actions: "You're offline — actions will sync when you reconnect."
When the connection returns and the queue's replaying: "Syncing your taps..."
Once the queue's empty: the snackbar dismisses itself.
The crew member doesn't have to do anything to trigger the sync. As soon as the device sees a network again, queued actions are sent one by one and the local state is updated with the server's response.
Setting up before an event
The trick to making sure offline works on the day is to make sure the device has cached the page at least once. Three pre-event steps that take a few seconds each:
Send the share link to crew at least a day or two before the event. The first time they open it, the device caches the page. They don't have to do anything special; just opening the link does it.
Suggest crew open the link on the same phone they'll have at the venue. Caching is per-device, per-browser. If they open it on their desktop and then arrive at the venue with only their phone, the phone won't have the cache.
Suggest crew avoid private browsing for the share link. Most modern browsers refuse to install service workers in private (incognito) mode, which means the offline cache won't be set up. Normal browsing mode is fine.
If a crew member opens the link for the first time on the day and the venue Wi-Fi is already flaky, they'll get the page if they can complete that one initial load, and then offline support kicks in for the rest of the event. The hard failure case is "first visit is at the venue AND first visit can't complete because there's no connection". The fix is to open it once at home.
Action queue behaviour
The action queue is per-share-link. If a crew member opens two different events on the same phone, their offline taps on one event don't interfere with the other.
The queue is stored in the browser's local storage, which means:
The queue survives a tab close and reload. A crew member who taps Start while offline, closes their browser, reopens an hour later, and is still offline, still sees the action queued.
The queue survives a phone restart. Local storage persists across browser sessions.
The queue does not survive a different browser. Tapping in Safari then switching to Chrome doesn't carry the queue. The crew member can finish their actions in either browser, but only the browser that did the tapping holds the queue.
If a crew member taps the same item multiple times while offline (Start, then Undo, then Start again), all three actions are queued in order and replayed in order when the connection returns. The end state matches what would have happened if they were online the whole time.
When things look weird
A few situations that have surprised crew before:
"My phone shows Offline but the venue says they have Wi-Fi." Connecting to a Wi-Fi network and actually reaching the internet are two different things. Some venues have a captive portal that requires the crew member to accept terms or enter a code through the device's browser before traffic flows. Until they do that, the device is "connected" but offline as far as the run sheet is concerned. Tell the crew to open any external site first to dismiss the portal, then come back to the share link.
"The run sheet looks out of date." If a crew member is offline (the pill says Offline) and the planner made changes recently, the crew member is looking at the last cached version. Their device hasn't seen the new state. Once they're back online, the page will refresh on its next polling cycle (within a minute) and pick up the new state.
"My tap didn't take." Most often this is the connection state in transition — the tap happened, but the network call timed out. If the pill says Offline, the action's in the queue and will replay. If the pill says Online, refresh the page and you'll see the truth (the action probably did go through; the response just didn't reach the browser).
What about the planner side
The planner page is not designed to work offline. It's a working tool you use from a laptop on stable Wi-Fi, not a tap-driven crew interface at the venue. If you're running an event from the planner page on your phone over flaky data, you'll feel it — that's the wrong tool for the job. Use the crew side for on-the-ground execution; the planner side is for setup, not for live operation.
Limits
Offline support requires a browser that has service workers enabled which is every mainstream browser on iOS, Android, Windows, and macOS for the last several years. The handful of exceptions:
Private / incognito browsing in Safari and Firefox blocks service workers.
Very old Android browsers (Android 4.x and earlier) don't have service worker support. Most crew won't be on these.
Devices that have storage pressure (very full phone, low-end hardware) may have their service worker cache evicted by the browser. Re-opening the share link on Wi-Fi restores it.
For everything else, offline at the venue should be a quiet feature that just works.
