Documenting the steps you use Auto Counter for means turning a live, time-driven counting session into a written record that someone else — or future-you — can repeat exactly. The tool counts once per interval while the page stays open, then writes each completed interval into a local daily history grouped by the device's calendar day, so the steps and the evidence already belong to the same place. A clean procedure captures five fixed decisions in order: a short label that names what is being counted, a whole-second interval between 1 and 3,600, the start moment, the pause rule that reconciles completed intervals, and the export format (PNG for a visual summary or CSV for a spreadsheet). Writing these down turns a one-off session into a repeatable workflow you can hand to a teammate, save in your runbook, or paste into a project notes file. The procedure is short by design — usually a single page — because every extra paragraph is a place the next operator can misread the rule and produce a record that no longer matches the original intent.
What "Documenting Your Auto Counter Steps" Actually Means
A documented Auto Counter procedure is not the counter itself; it is the human-readable set of choices that wraps around the counter so a session can be replayed without you standing over it. Most counting tasks fail to be repeatable because the operator remembers the interval in their head, names the run by feel, and decides whether to pause on a hunch. None of that survives a shift change, a sick day, or a six-month gap before the next audit. The point of writing the steps down is to externalize every choice that would otherwise live in someone's memory, and to attach each choice to the artifact it produces — a label, an interval, a daily total, and an export file.
The page is intentionally narrow. Auto Counter runs only while the browser tab stays open, uses Date.now inside timer callbacks, and stores a small JSON record under the counter:auto-counter key. That means the documentation should make the boundary visible too: a documented procedure has to say when the session starts, when it pauses, what happens to a tab that gets backgrounded, and what to do when the page closes. A runbook that hides those rules is not a procedure; it is a wish list.
The Five Decisions to Write Down
Every repeatable Auto Counter session rests on five decisions. Write each one down before the first Start press, because once the counter is running the interval control is locked and a later change cannot reinterpret time that has already passed.
| Decision | What to record | Where it shows up |
|---|---|---|
| Label | A short name that identifies the run | Stored locally next to the record; never embedded in exports |
| Interval | Whole seconds between 1 and 3,600 | Drives the math for every completed interval |
| Start moment | Date and device-local time of pressing Start | Anchors the elapsed-time calculation in the browser |
| Pause rule | When to reconcile and stop | Adds any completed whole intervals, then halts |
| Export format | PNG visual summary or CSV spreadsheet file | Generated in-browser with Blob and canvas APIs |
A common mistake is to skip the pause rule because "I'll know when to stop." A documented pause rule turns a vague judgement into an explicit trigger — when the kettle boils, when the last tray clears the line, when the observation window ends — so anyone following the procedure reaches the same Pause at the same logical moment.
Recording an Auto Counter Session Step by Step
Use this fixed order every time. Following the same sequence is what makes the resulting record comparable across sessions.
- Open the Auto Counter page and type a short label that names what you are counting — for example, "station B cycles" or "pomodoro blocks."
- Enter a whole-number interval in the seconds field, choosing a value between 1 and 3,600 that matches your process rhythm.
- Press Start at the moment the run should begin and leave the tab open; the page adds one count for every completed interval based on elapsed time.
- Keep the tab in the foreground while you work, since a browser timer is not a metronome and a hidden or busy tab can delay the next callback.
- Press Pause at the documented pause trigger; the tool reconciles every whole interval already completed and stops further automatic changes.
- Open the local daily history section, confirm the date and total match what you observed, and restart only when a new session boundary is clear.
- Export PNG for a visual record or CSV for a spreadsheet file, and save the export next to the written procedure so the two stay paired.
If a delayed callback finally runs after the tab was inactive for an unusually long stretch, Auto Counter stops rather than replaying old ticks, so the documented procedure should also say what to do in that case — usually note the gap in the run log and start a fresh session.
Using the Daily History and Exports as the Record
Auto Counter is unusual among simple counters because it produces two artifacts you can attach to the procedure: a daily history view inside the page, and a downloadable file. Both are generated client-side, which means no upload queue, no account, and no outside API sits between the count and the file on your disk. The history is grouped by the device's local calendar day, so a callback that crosses midnight assigns its completed intervals to the right day rather than forcing a single UTC date. That detail is worth writing into the procedure so a reviewer reading the file a week later understands the day boundaries.
The CSV export is a two-column Date and Automatic increments file, simple enough to drop into a spreadsheet, append to a monthly workbook, or diff against last month's run. The PNG export is a 1080 by 1350 share image with a total and recent day rows; it deliberately contains no web address and no custom counter label, which is a useful property for a documented record because the visual summary will not leak an internal note. If your procedure needs the label visible in the artifact, write it into the file name you give the export rather than asking the tool to embed it.
For deeper verification of the numbers in a completed run, pair the procedure with a short check-the-result walkthrough so anyone reading the file later can confirm the daily total matches their own hand count before they trust the export.
Writing the Procedure So a New User Can Follow It
A procedure that only the original author can follow is not documentation; it is a personal habit written down. To make the runbook usable by someone who has never opened the tool, write each step as an instruction the reader can verify. "Watch the page" is not a step; "leave the Auto Counter tab in the foreground while the kettle is on the stove" is. Replace every pronoun with the noun it stands for, every time reference with a clock time, and every judgement ("a while", "soon", "most of them") with a number or a visible trigger.
A tight written template looks like this: open the Auto Counter page, set the label to [run name], set the interval to [seconds] seconds, press Start at [clock time], leave the tab open until [stop trigger], press Pause, then export CSV as [file name]. The bracketed fields are the only places a new operator has to make a decision, and every bracket is a place the original author can pre-fill when the procedure is for a known recurring task. The WHATWG HTML Timers specification describes how browsers throttle background timers, which is the underlying reason the documented procedure has to say "leave the tab open" rather than assume it.
Keep the procedure in the same folder as the exported file. A runbook that lives in a wiki while the evidence lives in Downloads breaks the link between instruction and result; storing them together makes the next session a copy-paste exercise.
Where PNG, CSV, and a Written Note Each Fit
Not every documented Auto Counter session needs the same artifact. The choice depends on who will read the record and what they will do with it.
| Output | Best for | Limitation to note in the procedure |
|---|---|---|
| PNG image (1080 × 1350) | Visual summaries, slide decks, a quick scan in a chat thread | No web address and no custom label are embedded, so annotate externally |
| CSV file (Date, Automatic increments) | Spreadsheet pivots, monthly rollups, comparisons across months | Only saved dates appear; zero days are omitted rather than padded with zeros |
| Written note in the runbook | Capturing decisions the tool cannot record — why the interval was chosen, what counts as a pause trigger | Does not prove the count itself; pair it with one of the exports |
For most teams, the CSV is the canonical record because it can be summed, filtered, and audited, while the PNG is the friendly summary and the written note is the human context. Documenting the steps you use Auto Counter for is really about tying those three artifacts to a fixed decision sequence so the next person can produce all three without asking you.
One small worked example clarifies the math the procedure should describe. If the interval is set to 45 seconds and the run lasts 7 minutes, the elapsed time is 7 × 60 = 420 seconds. The number of completed intervals is floor(420 / 45) = 9, with a remainder of 420 − (9 × 45) = 420 − 405 = 15 seconds. The procedure should record 9 increments for that run, and note that 15 seconds of unfinished time carried into the next callback rather than being silently dropped — that is exactly how Auto Counter avoids undercounting when the browser delays a tick.
For a deeper look, see Should You Use Daily Habit Counter? A Decision Guide.