# Managing and maintaining stations > Running and maintaining a live fleet, remote actions, bulk jobs, configuration and presets, firmware, diagnostics, command history, maintenance access and the operational status lifecycle. Once a station is live, the platform is where you run and look after it. Because a live station holds an open [OCPP connection](/docs/platform/charge-point-operation/ocpp-connectivity) to the platform, almost everything here happens remotely, with no one visiting the site: acting on a station, pushing firmware, pulling diagnostics, and seeing exactly what it has done. ## Remote actions From a station you can: - **reboot** it, - **unlock a connector** to release a stuck cable, - **stop a running session**, - **change its availability**, so it stops accepting new charges while staying connected, - and send any other OCPP command the station supports. These act on the hardware over OCPP, so what a given station accepts depends on its firmware and OCPP version. See the [OCPP](/docs/emobility/ocpp) primer for the underlying commands. Separately, an administrator can **ban** a misbehaving station. A ban is not an OCPP command; it blocks the station at the connection layer, so it can no longer connect at all until it is unbanned. The reason is recorded. ## Working across many stations Doing any of that to a thousand stations by hand is not an option, so firmware pushes, configuration changes and arbitrary commands can be run across a selection as a **background job**. The job works through the stations on its own and reports the outcome for each one, so a failure on a single unit does not hold up the rest and you can see afterwards which took and which did not. ## Configuration and presets A station's OCPP **configuration**, its settings exposed as configuration keys, can be read and changed from the platform, one station at a time or across many as a background job. A **configuration preset** saves a set of those settings so a station, or a whole batch, can be brought to a known-good state in one step rather than key by key. Each provider keeps its own presets, and one can be marked as the default that is applied automatically the first time a new station connects. That default is the auto-configuration an installer relies on during [onboarding](/docs/platform/charge-point-operation/onboarding-stations). ## Firmware updates You can push a firmware update to a single station, or roll one out across a fleet as a background job. The platform delivers the update over OCPP and tracks each station's progress as it downloads and installs, so you can see whether it took. Firmware behaviour is specific to the hardware, so what a model accepts, whether it needs a signed image, and how it reports progress depend on the vendor and its OCPP version. ## Diagnostics and health When a station misbehaves you can ask it, from the platform, to upload its **diagnostics or logs**, and inspect them without anyone visiting the site. The platform also keeps a live view of each station's connectivity from its heartbeats and flags units that have gone quiet, and it raises problems it spots on its own, from lost connectivity to a faulted connector (see [charging station detected issues](/docs/platform/charge-point-operation/charging-station-detected-issues)). For uptime and availability over time, see [reliability reporting](/docs/platform/charge-point-operation/reliability-reporting). ## Command history Every message between a station and the platform is recorded, and you can browse a station's full **command history**: what was sent, when, and how the station replied. You can filter by message type or status, hide the noise of routine heartbeats and meter values, narrow to a time range, and export the result. This is the first place to look when a station is doing something unexpected, because it shows exactly what passed between the two. From the same place you can issue a command by hand when you need to prod a specific unit. ## Maintenance access A station can be handed to a **maintenance account**: a field-service or installer company that looks after the hardware without owning the station. A maintenance account sees only the stations it is responsible for, and from that view it can commission a unit, run the auto-configuration, manage the station's OCPP credentials, and test-charge with a **maintenance token**. A maintenance token charges for free, and only on a station that has not yet been claimed and billed, so an installer can prove a unit works before it is handed to its owner. ## Operational status Every station carries an **operational status** that says where it is in its life. The platform advances a station through **onboarding**, **activation** and **live** on its own, as each stage is configured (see [onboarding](/docs/platform/charge-point-operation/onboarding-stations) for those first stages): - **Onboarding**: the station is being set up, its connectors and OCPP settings configured. - **Activation**: its commercial setup is being completed, an account, a location, a billing plan and pricing. - **Live**: it is operational and charging, with its subscription billing running. Beyond that, taking a station **out of service** (temporarily not charging, but still billed) or **archiving** it (retired, billing stops) is a deliberate step. A provider can also define **statuses of its own** to match how it runs its fleet, a unit awaiting a part for instance, each mapping onto one of these. A station's status governs whether it charges, is billed, and is offered to the roaming network, so it is the lever an operator uses to take a unit in and out of service.