Most redstone guides hand you a schematic and a parts list. This one hands you the rules. Once you know the rules, you can read any schematic, fix any broken contraption, and design things nobody published yet.

This is the page to bookmark. It is the full reference: how power moves, what every component does, the exact tick timings, every common clock, the core circuits, and a debugging section for when a build refuses to work. It is long on purpose. Use the headings to jump to what you need.

Everything here is pinned to Minecraft 1.21.4 Java Edition. Redstone in Java is precise and deterministic, and the numbers below are exact. Where Bedrock differs in a way that matters, it is called out inline. Bedrock is not just "Java with different timing": it lacks quasi-connectivity, resolves block updates in a different order, and its pistons behave differently, so do not assume a Java design ports cleanly.

How redstone power works

Redstone is an electrical metaphor, but it does not obey real electronics. It has its own three rules, and almost every mistake beginners make is a violation of one of them.

The 0 to 15 signal

Every redstone signal carries a strength that is an integer from 0 (off) to 15 (full). There are no fractions and no values above 15. This single number is the heart of redstone.

  • A lever, button, redstone torch, or redstone block outputs strength 15.
  • Redstone dust loses 1 strength for every block it travels. A signal of 15 lights 15 blocks of dust, then dies on the 16th. This is the 15-block decay, and it is why long wires go dark.
  • A repeater resets a signal back to 15 (and can delay it), which is how you carry power across long distances.
  • A comparator never amplifies. It passes a signal through at the strength it received, or outputs a strength it calculates from its inputs. It can reduce strength but never raise it.

Hold that last contrast. A repeater is a booster and a delayer. A comparator is a measurer and a comparer. They look alike with their little torches, but they do opposite things to strength. The full treatment of measurement and signal strength lives in the comparator and signal strength guide; this handbook gives you the working summary.

The cheapest debugging tool in redstone is a line of dust. Run the signal you are unsure about into a straight line of redstone and count how many blocks stay lit. Seven lit blocks means strength 7. You never have to guess what a wire is carrying; you can read it directly in survival with no commands.

Hard power versus weak power

This is the distinction that trips up intermediate builders, and understanding it removes a whole class of "why won't this block power the dust next to it" problems.

A powered solid block can be powered in one of two ways:

  • Strongly powered (hard power): the block is powered by a component that strongly powers it, such as a redstone torch underneath it, a repeater or comparator pointing into it, or a button or lever attached directly to it. A strongly powered block powers adjacent redstone dust as if it were a source.
  • Weakly powered (soft power): the block is powered because powered redstone dust is sitting on top of it or running into it. A weakly powered block powers components that read it directly (like a repeater pointing out of it or a piston) but does not re-power redstone dust running alongside it.

The practical takeaway: dust does not jump through a block that is only weakly powered. If you power a block with a torch under it, dust on the far side lights up. If you power that same block only by running dust into it, dust on the far side stays dark. This is "block powering" versus "dust powering," and it is the reason vertical and through-block transmission feels inconsistent until you internalize it.

Components, sources, and the update model

Redstone reacts to block updates, not to power directly. When a block changes state (a lever flips, a piston extends, a block is placed) the game sends an update to neighbouring blocks, and those neighbours recompute their power. Update order is what determines which of two things fires first when both change in the same tick. For the deep version of this, including quasi-connectivity, see the observer, BUD, and quasi-connectivity guide.

One timing fact to anchor everything below:

1 redstone tick = 2 game ticks = 0.1 seconds. The game runs at 20 game ticks per second. A "tick" in casual redstone talk almost always means a redstone tick (0.1s), but exact circuit timing is measured in game ticks (0.05s).

Redstone dust: the wire

Redstone dust is the wire that carries signal between components. Its behaviour is simple but has sharp edges.

  • Dust decays 1 strength per block. Place a redstone block (strength 15) and the dust lit beside it reads 15, the next block 14, and so on to 0.
  • Dust connects automatically to adjacent dust, components, and to dust one block up or down on the side of a solid block (it climbs and descends stairs of full blocks).
  • Dust has a connection state: a single dot, a line, or a cross, depending on what it touches. You can force a "dot" (no directional connection) by right-clicking a piece of dust, which toggles it between connected and dot modes. This matters when two wires must cross without merging.
  • Dust does not climb glass, slabs, or transparent blocks. It needs a full solid block to run up a wall.
  • To carry a signal straight up cheaply, alternate solid blocks in a staircase and let the dust climb the sides, or use a vertical column of redstone torches (each torch powers the block above it, the next torch sits on that block). The torch-tower method is slower but takes a 1-wide footprint.

The redstone torch

The redstone torch is a source and an inverter in one block.

  • A free-standing torch outputs strength 15 to the dust around it and to the block above it.
  • A torch attached to the side of a block, or sitting on top of one, inverts that block's power: when the block is unpowered the torch is on, and when the block is powered the torch turns off. This is the fundamental NOT gate.
  • A torch powers the block directly above it (strongly), and the dust beside it (the block it is attached to is not powered by its own torch).

Torch burnout

If a redstone torch is forced to change state too fast, it burns out: it turns off and stays off until it receives a block update that lets it recover. Specifically, a torch that toggles more than a few times within a short window will lock off.

  • The practical rule: a torch toggling faster than roughly once every 2 game ticks, sustained, will burn out.
  • This is why a torch cannot safely drive the fastest clocks. A "torch clock" built from an odd loop of torches runs, but it sits right at the edge of burnout and is famous for jamming.
  • Burnout clears when the torch gets a block update after the rapid toggling stops. If a circuit "dies" after running fast, suspect torch burnout first.

Do not build fast clocks out of redstone torches. They will burn out and the circuit will lock. Use a repeater clock or an observer clock for anything that needs to run continuously. Save torches for inversion, slow logic, and one-shot signals.

The repeater

The repeater does three jobs: it boosts, it delays, and it acts as a one-way diode. It is the workhorse of clean redstone.

  • Boost: a repeater outputs strength 15 regardless of the input strength, as long as the input is at least 1. Drop a repeater into a fading wire and the signal leaves at full strength again.
  • Delay: right-click a repeater to set its delay to 1, 2, 3, or 4 redstone ticks (0.1s, 0.2s, 0.3s, 0.4s). The two movable torches on top show the setting. This is your primary timing tool.
  • Diode: a repeater only passes signal in the direction of its arrow. Signal cannot flow backward through it. This makes it the standard way to prevent a circuit from feeding back into itself.

Repeater locking

A repeater can be locked. Power a repeater from the side (with another repeater or comparator pointing into its side) and it freezes in its current state: if it was on it stays on, if off it stays off, ignoring its rear input until the side power is removed.

  • Locking turns a repeater into a 1-bit memory cell (a latch). This is the basis of many flip-flops and display drivers.
  • A locked repeater is visually obvious: a small bedrock-textured bar sits across the top of it.

Repeater delay is your finest timing control short of game-tick precision. If you need a delay that is not a clean multiple of a repeater setting, chain repeaters: four repeaters at 4 ticks each give 16 redstone ticks (1.6s). For exact arbitrary periods, the on-site Redstone Calculator decomposes any target into a minimal repeater layout.

The comparator

The comparator measures and compares. It has a torch on its front face that toggles its mode, and it can read the contents of containers. This is the most powerful and most misunderstood block in redstone, so the short version follows and the full version is in the dedicated comparator guide.

Compare versus subtract

  • Compare mode (front torch off): outputs the rear input unchanged, unless a side input is stronger, in which case it outputs 0. It answers "is my main signal still the strongest?"
  • Subtract mode (front torch on): outputs rear input minus the larger side input. Back 12, side 5, output 7. It answers "what is left of my main signal after I take the side away?"

The comparator has a rear input (the main signal), two side inputs, and a front output. The arrow on top points toward the output.

Container readouts

Point a comparator's back out of a container and it outputs a signal strength proportional to how full the container is, from 0 (empty) to 15 (full). The fill is computed across all slots, so a chest with one item reads 1, not something high. This single feature drives item sorters, auto-smelters, and storage-full detectors.

  • Special blocks read other states: a cauldron reads fluid level, a composter reads fill stage (0 to 8), a furnace and brewing stand read their slots, an item frame reads item rotation (0 to 7), a cake reads bites remaining, and a lectern reads the current page of an open book.

Combine the comparator's readout with the rest of this handbook and you get state-driven machines: the comparator supplies the information, the repeaters and pistons supply the timing and the motion. The full storage application of this is the automatic item sorter build.

Pistons and sticky pistons

A piston pushes blocks. A sticky piston pushes and pulls them. They are the only blocks that move other blocks in vanilla, which makes them the muscle of every door, elevator, and flying machine.

The push limit and basic behaviour

  • A piston extends when powered and pushes up to 12 blocks in a line. The 12-block push limit is hard: try to push 13 and the piston does nothing.
  • A regular piston pushes on extend and leaves the block behind when it retracts (the head returns empty).
  • A sticky piston pushes on extend and pulls the block back on retract. It only pulls the single block touching its head.
  • Pistons take 3 game ticks to extend and a similar time to retract. This delay matters for timing-sensitive builds; a piston is not instantaneous.

Block-drop quirks

  • Most pistons cannot push block entities (chests, furnaces, hoppers, droppers, dispensers, beds, and similar). A piston facing one of these simply does not extend.
  • Pistons cannot push obsidian, bedrock, reinforced deepslate, or any tile-entity block in the immovable list. Always check the moveable-blocks list before designing around pushing a new block type.
  • Gravity blocks (sand, gravel, concrete powder) pushed sideways stay placed, but if the support is removed they fall. Pushing them up and then removing the piston can drop them.
  • A classic quirk: pulling a block with a sticky piston faster than 2 game ticks after extending can leave the block behind (the head retracts but the block does not follow). This "0-tick" and "pulse-too-short" behaviour is exploited in some droppers but is a bug source in normal builds.

Slime and honey

  • A slime block sticks to every adjacent block (except honey and a few exceptions) and carries them when a piston moves it, up to the 12-block limit counting the whole connected group.
  • A honey block behaves the same as slime for movement but does not stick to slime blocks. Placing a honey block between two slime segments creates a deliberate break point in an attachment chain. Honey also slows entities standing on it.
  • This stickiness is what makes flying machines and large moving doors possible. The mechanics in depth are in the observer and flying machine guide, and the door applications are in the piston doors guide.

The 12-block push limit counts every block in the connected slime or honey group, not just the line in front of the piston head. A flying machine that suddenly jams almost always grew past 12 attached blocks. Count your passengers, and use honey blocks to split a heavy group into pushable chunks.

The observer

The observer watches the block directly in front of its face and emits a redstone pulse when that block changes state.

  • The pulse is 2 redstone ticks (0.1s) long and comes out of the back (the small dot face), the opposite side from the watching face.
  • Observers detect block state changes: a block placed or broken, a crop growing, a piston extending, a door opening, dust changing connection, a redstone block appearing.
  • Observers do not detect entities, players walking through, or items on the ground. Those are not block state changes.
  • In Bedrock, an observer also fires when first placed, and the output face differs visually; Java observers do not pulse on placement.

Two observers facing each other form a self-sustaining clock (covered below). Observers replaced most BUD switches for everyday block-change detection. The trade-offs between observers, BUD switches, and quasi-connectivity are the entire subject of the observer and BUD guide.

Droppers, dispensers, and hoppers

These three move items, and they are the backbone of storage, farms, and sorters.

Dropper

  • A dropper ejects one item from a random occupied slot when it receives a redstone pulse. If it faces a container, it transfers into that container instead of spitting the item out.
  • Chaining droppers into a loop (a "dropper line") moves items vertically or around corners; each pulse advances one item.

Dispenser

  • A dispenser looks like a dropper but uses items rather than dropping them: it shoots arrows, places water or lava from buckets, plants saplings, shears sheep, fires fireworks, and applies bone meal. If the item has no special behaviour, it drops it like a dropper.
  • A dispenser fires once per redstone pulse (a rising edge). Hold it powered and it fires once, not continuously.

Hopper

  • A hopper moves items into the container it points into, and pulls items from a container directly above it.
  • Transfer rate is 1 item every 8 game ticks (0.4s), which works out to 2.5 items per second per hopper. This number governs the throughput of every item sorter and storage system.
  • A hopper is disabled while powered. Apply redstone power to a hopper and it stops moving items. This is how you gate item flow on a clock or a fullness signal.
  • A hopper minecart moving over a hopper or chest pulls items faster than a static hopper, which is why high-throughput collection floors use hopper minecarts.

The "hopper is disabled while powered" rule is the single most useful item-logic fact in redstone. Combine it with a comparator reading a container and you build storage that fills evenly, stops when full, or routes overflow. The full item-sorter pattern (a row of hoppers with item filters and a comparator clock) is built up step by step in the item sorter guide.

Inputs: switches, plates, and sensors

These are the blocks that start a signal. Knowing each one's output strength and pulse behaviour saves a lot of trial and error.

  • Lever: toggles on or off, outputs 15, stays in whatever state you set. The only true permanent manual switch.
  • Button: a momentary push. A stone button stays on for 10 game ticks (1.0s, a 1-second pulse); a wooden button stays on for the same duration but can also be triggered by an arrow. Outputs 15 while held.
  • Pressure plate (stone/iron): activates while an entity stands on it. Stone plates react only to mobs and players; wooden plates react to any entity including items and arrows. Output is 15 while occupied.
  • Weighted pressure plate (gold/iron): outputs a strength proportional to the number of entities on it. The light (gold) plate caps at fewer entities for full strength; the heavy (iron) plate needs many more entities to reach 15. Use these for entity counters.
  • Tripwire hook with string: a tripwire across a gap outputs 15 when any entity crosses the string. Two hooks and a line of string make a wide, hidden trigger.
  • Target block: outputs a strength based on how close to center a projectile hits it, from 1 (edge) to 15 (bullseye). It also passes signal through when hit. Great for archery puzzles and skill doors.
  • Lectern: with a book open, it outputs a comparator-readable strength equal to the current page number. Turning the page changes the signal, which makes a lectern a manual multi-state selector.
  • Daylight sensor: outputs a strength based on sky light level, peaking at noon. Right-click it to invert it so it powers at night instead. The standard trigger for day/night automation and street lights.
  • Sculk sensor and calibrated sculk sensor: detect vibrations (sounds and movement) and emit a signal. The calibrated variant can be tuned with a comparator on its side to listen for one specific vibration frequency, filtering out everything else. This is the wireless-trigger block of modern redstone.

Transmission: moving a signal where you need it

Getting a signal from A to B intact, around corners, up walls, and across long distances is half of redstone engineering.

  • Dust is the default wire but decays 1 per block, so it only reaches 15 blocks.
  • Repeaters reset to 15 and let you run indefinitely. Place one at least every 15 blocks; in practice builders place one every 8 to 15 blocks for clean signal.
  • Redstone blocks are a permanent strength-15 source you can place and move. A redstone block carried by a slime-piston is a moving power source, which is how some flying machines self-power.
  • Vertical transmission options: a staircase of solid blocks with dust climbing the sides, a torch tower (one torch per block, slow), or a "redstone ladder" of alternating blocks and dust. There is no single perfect vertical wire; pick by footprint versus speed.
  • Quasi-connectivity lets a piston be powered from the block diagonally above its rear, which some compact transmission tricks exploit. It is a Java-only behaviour and is explained fully in the observer and BUD guide.

A frequent surprise: signal behaviour can change at chunk borders because of how chunks load and tick. If a contraption works in one spot and breaks 20 blocks away, suspect a chunk boundary. The mechanics of ticket levels and why redstone stalls at chunk edges are covered in why redstone breaks on chunk borders.

Clocks: signals that repeat

A clock is any circuit that outputs a repeating on/off pulse. Choosing the right clock is mostly about the period you need and whether you can turn it off.

Repeater clock (loop clock)

The most reliable adjustable clock. Run a loop of dust through repeaters back into itself, with a redstone torch or an odd element to keep it oscillating, and tap the output.

  • Period is set by the total repeater delay in the loop. Two repeaters at 4 ticks each give a slow, steady clock.
  • Strengths: adjustable, stable, does not burn out. Weakness: takes horizontal space.
  • This is the default clock for farms and timed machines. Use the Redstone Calculator to turn a target period into the exact repeater layout.

Hopper clock

The most precise slow clock. Two hoppers face into each other, and a fixed number of items shuttles back and forth; a comparator reads each hopper and flips the output when it empties.

  • Period scales with the item count: each item adds 8 game ticks (0.4s) per direction because of the hopper transfer rate. A single item per hopper gives a fast cycle; loading 20 items gives multi-second periods.
  • Strengths: extremely stable, tunable to long periods by adding items, compact. Weakness: the period is in 0.4s steps, so it is not arbitrarily fine.

Comparator clock

A compact, fast clock built from one comparator feeding back into its own side input through a short loop.

  • Produces a fast pulse, often used to rapidly toggle something like a hopper gate or a sorter feed.
  • Period is short and depends on the loop length; add a repeater in the loop to slow it. A comparator clock with no repeater runs near the fastest stable rate.
  • Strength: tiny footprint. Weakness: the raw version runs very fast and can overwhelm slow components.

Observer clock

The simplest fast clock: two observers facing each other.

  • Each observer detects the other's state change and re-triggers. The cycle is 4 game ticks (0.2s) per full period (2 ticks per observer reaction).
  • Strengths: one block wide, no dust, no burnout. Weakness: fast and not adjustable without adding delay components. Stopping it requires breaking the update chain (for example, a piston pulling one observer out of line), not just cutting redstone.

Match the clock to the job. Fast toggling (sorters, droppers): observer or comparator clock. Adjustable general timing: repeater clock. Precise long periods (farm cycles, day timers): hopper clock. Never reach for a torch clock; it burns out. And remember a running clock burns CPU every tick whether or not anything is happening, so prefer event-driven observer triggers when the world itself can signal you.

Core circuits

These are the building blocks of every complex machine. Learn the pattern, not just the schematic, and you can rebuild any of them from memory.

Logic gates

Logic gates combine input signals into an output by a rule.

  • NOT gate (inverter): a redstone torch on a block. Input powers the block, the torch turns off. Output is the opposite of the input. The single most common gate in redstone.
  • AND gate: output is on only when all inputs are on. The standard build feeds each input through a torch (inverting it) into a shared block, then inverts the result with one more torch. Two inputs in, both must be on for the output.
  • OR gate: output is on when any input is on. The simplest gate of all: just merge the input wires onto one piece of dust. Any powered input lights the output.
  • NOR gate: OR followed by NOT. Merge inputs onto a block and put a torch on it. Output is on only when no input is on. NOR is the cheapest gate to build and many designs are NOR-based for that reason.
  • NAND gate: AND followed by NOT. Output is off only when all inputs are on.
  • XOR gate (exclusive or): output is on when the inputs differ (exactly one on). This is the gate behind T flip-flops and adders. A compact XOR uses two inputs, each feeding a torch arrangement so that matching inputs cancel and differing inputs pass.
  • XNOR gate: XOR followed by NOT. Output is on when the inputs match. Used in equality checks and combination locks.

Every gate reduces to torches (NOT) and wire merges (OR). If you can build a NOT and an OR, you can build every gate in the list by composition. Memorize those two and derive the rest.

Pulse extender (pulse lengthener)

Takes a short pulse (say a 2-tick observer output) and stretches it into a longer one so a slow component has time to react.

  • The simplest version feeds the pulse into a chain of repeaters set to long delays; the output is held for the sum of the delays plus the input.
  • A cleaner version uses a circuit where the rising edge sets a latch and a delayed copy of the signal resets it after a fixed time.
  • Use it whenever a fast trigger (observer, button) must drive a slow action (a long piston sequence, a dispenser that needs a clean edge).

Monostable (pulse limiter / pulse shortener)

The opposite of a pulse extender: it takes any input, even a held one, and emits a single fixed-length pulse.

  • The classic build feeds the input into a torch through a delayed feedback line, so the output turns itself off after a set delay regardless of how long the input stays on.
  • This is how you turn a lever (held on) or a long button press into a clean one-shot pulse for a dispenser or a door.

Edge detector

Fires a short pulse on a transition rather than on a held state.

  • A rising-edge detector pulses when the input turns on. Build it by ANDing the input with a slightly delayed, inverted copy of itself: the two only overlap for the moment after the input rises.
  • A falling-edge detector pulses when the input turns off, built the mirror way.
  • Dual-edge detectors pulse on both. An observer is effectively a hardware edge detector for block changes.
  • Edge detectors convert "the lever is on" into "the lever just turned on," which is exactly what dispensers and one-shot machines need.

T flip-flop (toggle)

The memory cell that toggles state on each input pulse: press once for on, press again for off. This is what turns a button into a switch.

  • The compact 1.21.4 build uses a sticky piston with a redstone block on top: each pulse extends or retracts the piston, moving the redstone block between powering and not powering an output. It is a one-block-tall mechanical toggle and the most popular T flip-flop today.
  • A purely-dust T flip-flop exists (using paired repeater latches and an XOR feedback) but the piston version is smaller and easier to read.
  • Use it for lights, doors, and any "press to toggle" control off a momentary button.

RS latch (set-reset memory)

Stores one bit. A pulse on Set turns the output on and it stays on; a pulse on Reset turns it off and it stays off.

  • The classic build is two NOR gates cross-coupled: each NOR's output feeds the other's input. Set and Reset are the spare inputs.
  • This is the simplest memory in redstone and the foundation of registers and saved state. A locked repeater (covered above) is a one-block latch for the same purpose.

The piston T flip-flop, the NOR RS latch, and the locked repeater are the three memory primitives worth knowing by heart. Almost every "remember a state" requirement in a build is one of these three. Pick the latch for set/reset logic, the T flip-flop for toggling, and the locked repeater when you need memory in a one-block footprint.

Pistons in practice: doors and contraptions

Putting pistons, observers, and timing together gives you the contraptions players actually want: hidden doors, item elevators, and auto-farms.

  • 2x2 piston door: four sticky pistons, two pushing the upper blocks and two the lower, fired together by a clean pulse. The timing must be tight or the blocks desync. The full set of door designs, from simple flush doors to large vault doors, is in the piston doors guide.
  • Item elevators: a column of droppers, each pulsed by a clock, walks items upward; a comparator at the top stops the clock when the destination is full.
  • Auto-farms: an observer watches a crop, fires when it matures, and a piston or water dispenser harvests it. This event-driven pattern wastes no ticks because nothing fires until the world changes, unlike a clock that runs constantly.

The lesson that ties pistons together: design around the 3-tick piston delay and the 12-block push limit. Most piston-build failures are a pulse that arrives before the previous piston finished moving, or a group that quietly grew past 12 blocks.

Common mistakes and debugging redstone

When a build does not work, it is almost always one of a small set of causes. Run this checklist before tearing anything down.

  1. The signal faded out. Dust only travels 15 blocks. Count the distance and add a repeater. This is the number-one cause of "the far end does nothing."
  2. Weak power versus strong power. Dust is not jumping through a block because the block is only weakly powered (powered by dust, not by a torch or repeater). Power the block strongly, or route the dust around it.
  3. A comparator side input is killing the output. If a comparator reads 0 when you expect a value, a side input equals or exceeds the back input. Check both sides.
  4. Comparator mode is backwards. Lit front torch is subtract, unlit is compare. If arithmetic looks inverted, toggle the torch.
  5. The pulse is too short or too long. Pistons need 3 game ticks to move; observers emit only a 2-tick pulse. If a slow component misses a fast trigger, add a pulse extender. If a dispenser fires repeatedly when it should fire once, add an edge detector or monostable.
  6. Torch burnout. A circuit that runs fast then dies has burned out a torch. Slow the clock or rebuild it without torches.
  7. A repeater is pointing the wrong way or is locked. Repeaters are one-way. Check the arrow. If one has a bar across the top, a side input has locked it.
  8. Quasi-connectivity surprise. A piston firing when "nothing" is powering it is being triggered by power one block diagonally above its rear. This is Java QC; see the observer and BUD guide.
  9. It works here but breaks over there. Chunk borders change tick behaviour. See redstone on chunk borders.
  10. It worked in a different version. Update order changed subtly between major versions. A BUD or 0-tick design from an old tutorial may misfire in 1.21.4. Test on a disposable world before committing it to a real base.

Debug one stage at a time. Cut the circuit into its inputs, its logic, and its output, and test each in isolation with a lever and a lamp. A line of dust to read signal strength, plus a lamp to read on/off, will localize almost any fault in a couple of minutes. Resist the urge to rebuild the whole thing; the bug is usually one block.

Quick reference tables

Bookmark this section. It is the cheat sheet you will come back to most often, gathered in one place so you do not have to re-derive a number mid-build.

Output strength of every input

These are the strengths a freshly triggered input puts onto adjacent dust, before any decay.

Input Output strength Notes
Lever 15 Stays until toggled
Button (stone) 15 10 game ticks, then off
Button (wooden) 15 10 game ticks, also fired by arrow
Redstone torch 15 Inverts the block it is on
Redstone block 15 Permanent, movable source
Pressure plate (stone/iron) 15 On while occupied
Weighted plate (gold/iron) 1 to 15 Scales with entity count
Target block 1 to 15 Scales with hit accuracy
Daylight sensor 0 to 15 Scales with sky light
Comparator (container) 0 to 15 Scales with fullness
Lectern 0 to 15 Equals open page number
Sculk sensor varies Based on detected vibration

Timing constants

Every number a redstone timing problem usually needs.

  • 1 game tick = 0.05s. The game runs at 20 game ticks per second.
  • 1 redstone tick = 2 game ticks = 0.1s.
  • Repeater delay = 1 to 4 redstone ticks (0.1s to 0.4s), set by right-click.
  • Observer pulse = 2 redstone ticks (0.1s, 4 game ticks).
  • Piston extend/retract = roughly 3 game ticks each.
  • Hopper transfer = 1 item per 8 game ticks (0.4s), so 2.5 items/second.
  • Stone/wooden button = 10 game ticks on (1.0s).
  • Observer clock period = 4 game ticks (0.2s) per full cycle.

Movement limits

  • Piston push limit = 12 blocks, counting the whole connected slime/honey group.
  • Dust travel = 15 blocks before decaying to 0.
  • Sticky piston pull = exactly 1 block (the one touching the head).
  • Repeater spacing = place one at least every 15 blocks; in practice every 8 to 15.

Logic gate cheat sheet

Gate Output is on when
NOT Input is off
AND All inputs are on
NAND Not all inputs are on
OR Any input is on
NOR No input is on
XOR Inputs differ (exactly one on)
XNOR Inputs match

Frequently asked questions

What is the difference between a game tick and a redstone tick?

A game tick is 1/20 of a second (0.05s); the game runs at 20 game ticks per second. A redstone tick is 2 game ticks (0.1s) and is the unit repeaters use. Repeater delays of 1 to 4 are in redstone ticks. When a guide says "2-tick pulse" for an observer, it means 2 redstone ticks, which is 0.1 seconds and 4 game ticks. Always check which unit a source means; mixing them is a common timing error.

Why does my redstone dust stop after 15 blocks?

Dust loses 1 signal strength per block, and the maximum strength is 15, so a signal dies on the 16th block. Place a repeater to reset the signal to 15 and continue. This is intended behaviour, not a bug, and it is the main reason long wires need repeaters.

Why does a block power some dust but not other dust next to it?

Because of weak versus strong power. A block powered only by dust running into it (weak power) does not re-power dust on its other faces. A block powered by a torch, repeater, or comparator (strong power) does power adjacent dust. To fix dead dust beyond a block, power that block strongly or reroute the wire so it does not pass through a weakly powered block.

What is the fastest clock I can build safely?

An observer clock (two observers facing each other) runs at a 4-game-tick period (0.2s) and never burns out, which makes it the practical fast clock. A comparator clock can run even faster but can overwhelm slow components. Avoid torch clocks entirely; they burn out under sustained fast switching.

How many blocks can a piston push?

Up to 12 blocks in a line. The limit counts every block in a connected slime or honey group, not just the column in front of the head. Pistons cannot push block entities (chests, hoppers, furnaces) or blocks on the immovable list (obsidian, bedrock, and similar). A sticky piston pulls back only the single block touching its head.

How fast does a hopper move items?

One item every 8 game ticks, which is 0.4 seconds, or 2.5 items per second. A hopper is disabled while powered, which is how you gate item flow. For faster collection, a hopper minecart moving over containers pulls items more quickly than a static hopper. The throughput of every sorter and storage system is governed by this 8-tick rate; the full design is in the item sorter guide.

Does any of this work the same on Bedrock?

Partly. Signal strength, the 15-block decay, repeater delays, and most components behave similarly. But Bedrock has no quasi-connectivity, resolves block updates in a different order, and its pistons and observers differ in timing and edge cases. Treat a Java design as a starting point on Bedrock and test it, rather than assuming it ports unchanged.

Where do I go next?

Pick the rabbit hole that matches what you are building. For measurement and analog logic, the comparator and signal strength guide. For block-change detection and flying machines, the observer, BUD, and quasi-connectivity guide. For storage automation, the item sorter guide. For hidden bases, the piston doors guide. And when a working build breaks for no reason, why redstone breaks on chunk borders.


Sources & further reading: